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axis  rate  gyroscopes.  The  C&DH  system  was  responsible  for  storing  and  running  all  of  the  spacecraft’s  software  and  controlling  all  of  the  other  systems  - 
tested  using  two  different  computers:  the  Arcom  Viper  and  the  Arcom  Mercury.  The  communications  system  was  designed  for  establishing  a  two  way 
communications  link  between  the  spacecraft  and  a  ground  station  (full-duplex),  using  separate  radios  and  frequencies  for  ground-to-satellite  and  satellite- 
to-ground  links.  The  mechanisms  system’s  primary  objective  was  to  safely  secure  all  deployable  systems  during  launch,  release  the  deployable  system 
when  commanded  during  the  mission,  and  to  deploy  the  systems  on  command.  DINO  had  four  deployable  systems:  the  antenna  release,  the  Boom  release 
and  slow  down,  the  FITS  release,  and  the  CTD  hinge  experiment  release  and  deployment.  The  mission  operations  system  was  responsible  for  controlling 
and  monitoring  the  satellite  with  a  minimum  of  human  intervention.  The  electrical  power  system  was  responsible  for  collecting,  managing,  and 
distributing  power  for  the  entire  spacecraft  -  a  direct  energy  transfer  system  with  a  secondary  lithium-polymer  battery  for  the  main  satellite,  a  primary  28V 
battery  for  the  deployable  devices,  a  main  solar  array,  the  Foldable  Integrated  Thin-film  Stiffened  (FITS),  and  body-mount  solar  arrays. 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  Univerisity  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1.3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1.4  Document  Overview 

The  atmospheric  torques  which  will  be  imposed  upon  DINO  in  orbit  are  critical 
to  the  design  of  the  ADC  system.  The  torques  applied  to  DINO  will  affect  the 
attitude  of  the  spacecraft,  which  the  ADC  system  will  need  to  maintain. 

1 .5  Referenced  Documents 

List  any  reference  documents  here. 

2  Atmospheric  Torque  Calculations 

According  to  the  MSIS90  density  plots,  at  300  km  we  expect  to  see  atmospheric 
density  values  of  approximately  10'13  3  g/cm3  (5.012  x  10'"  kg/m3)  at  solar  maximum 
and  10'14  g/cm3  at  solar  minimum.  The  torque  applied  to  the  DINO  spacecraft  will 
be  dominated  by  atmospheric  drag  torques.  Hence,  DINO’s  gravity  gradient  torques 
should  be  capable  of  compensating  for  this  external  torque. 

The  relationship  between  atmospheric  drag  and  atmospheric  density  is  approximated 
by  the  following  equation: 


lr  A  2 

aDrag  ~ 

I  m 


Eq.  2-1 
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where  Co  is  the  coefficient  of  atmospheric  drag,  A  is  the  cross-sectional  area  of  the 
spacecraft,  m  is  the  mass  of  the  spacecraft,  p  is  the  atmospheric  density,  and  v  is  the 
velocity  of  the  spacecraft  with  respect  to  the  atmosphere.  To  determine  the  torque  on 
DINO,  we  have  approximated  DINO  as  two  masses  separated  by  a  rigid,  massless 
rod  with  the  following  parameters: 


Table  2-1 


nmmm 

i1:  -  i.i  >mmmm 

Co 

2 

2 

A 

0.125  m2 

0.026  m2 

m 

25  kg 

5  kg 

P 

5.0119  x  10‘n 

5.01 19  x  10'" 

kg/m3 

kg/m3 

V 

7,726  m/s 

7,726  m/s 

Using  the  values  shown  in  the  table  above,  we  can  determine  an  approximate  value 
for  the  atmospheric  drag  that  each  half  of  DINO  experiences.  We  find  the  following 
values: 


Table  2-2 


m 

f§g , 

& Drag 

■BiH&snsmMi 

-1.556  x  1  O'5  m/s2 

Now  we  can  determine  the  net  torque  on  the  DINO  system  using  the  following 
relationship: 


^ Drag  ~  * Main  X  ^Main  +  Fip  X  & Tip 


Eq.  2-2 


where  retain  is  the  vector  from  DINO’s  center  of  mass  to  the  main  satellite,  F Main  is 
the  force  of  drag  on  the  main  satellite,  rTip  is  the  vector  from  the  center  of  mass  to  the 
tip-mass,  and  Fnp  is  the  foce  of  drag  on  the  tip-mass.  In  this  case,  assuming  a 
circular  orbit  and  a  nadir-pointing  spacecraft,  the  vectors  are  perpendicular  and  we 
can  directly  multiply  the  magnitudes  of  each  vector.  The  values  are  given  in  the 
following  table: 


Table  2-3 


.!•  -  _  ->T  -  1  -  t  -  C  1 

M 

LI  6 

5*  LI  6 

_ a _ 

3.7395  x  10^  N 

7.7783  x  10"5  N 
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L  is  equal  to  the  length  of  the  tether,  equal  to  retain  +  mP.  The  two  forces  produce 
opposing  torques.  If  we  assume  a  length  L  equal  to  20  meters,  we  expect  to  see  a  net 
atmospheric  torque  equal  to  approximately  4.99  x  10'5  Nm.  The  figure  below  shows 
the  relationship  of  atmospheric  torque  as  a  function  of  tether  length  for  DINO. 


Atmospheric  Torque  for  DINO 


Figure  2-1 


The  general  relationship  for  the  magnitude  of  the  atmospheric  torque  as  a  function  of 
main  satellite  mass,  tip-mass  mass  and  tether  length  is  the  following: 


T  = 

atm 


(  \  m  Main™  Tip  T 

A®  Tip  ~  @  Main  ) - j - L 

m  ' 


Main  ^  Tip 


Eq.  2-3 


We  will  define  the  following: 


m  - 


mMainmT,P 
mMain  +  mTiP 


Eq.  2-4 
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Thus: 


T  atm  ~  aTip  a  Main  m  ^ 


Eq.  2-5 


If  we  then  go  on  to  determine  the  length  of  tether  we  need  to  compensate  for  the 
atmospheric  torque  by  way  of  a  gravity-gradient  torque. . . 

The  moment  of  inertia  of  DINO  can  be  approximated  by  the  following  expression: 


I  ~  m  Main7 Main  mTip7Tip 


Eq.  2-6 


where,  once  again,  r^am  is  the  distance  between  the  main  satellite  and  DINO’s  center 
of  mass  and  rTip  is  the  distance  between  the  tip-mass  and  the  CG.  We  also  know  that 
mMainrMain=  mTiPrTiP  and  rMain  +  rTip  =  L  > the  length  of  the  tether.  Hence,  we  can  infer 
the  following  expression: 


7  * 

1  +  -^ 


+  mTip 


^ Main  j ^ 


j  _l_  mMain 


which  simplifies  to: 


and  again  to: 


finally: 


Jrj  mMain^Tip  +  ™ Tip™ Main  r2 
{mMain+mTipf 


171  Main171  Tip  j2 


mMain  +  mTip 


I  zsm  L 


Eq.  2-7 


Eq.  2-8 


Eq.  2-9 


Eq.  2-10 
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Now,  we  want  the  gravity-gradient  torque  to  fully  compensate  for  the  atm  drag 
torque.  Hence,  gr  >  ratm  .  A  simplification  of  the  gravity-gradient  torque  can  be 
represented  as  the  following: 


gr  *3 a2 1 


Eq.  2-11 

where  co  is  the  angular  velocity  of  the  spacecraft  as  it  orbits  the  earth.  DINO’s 
angular  velocity,  assuming  an  ISS  orbit,  is  roughly  equal  to: 

x  CO w 


Eq.  2-12 


where  //e  is  the  earth’s  gravitational  parameter.  Hence,  co  is  equal  to  about  1.157  x 
10"3  rad/s.  Thus  we  have  the  following: 

8,=34'>'- 

r 

Eq.  2-13 


or: 


3^(m'L2)>\aTip-aMJm'L 


Eq.  2-14 


which  simplifies  to: 


L  >  aTip  a  Main 


Eq.  2-15 


given  our  orbit  and  accelerations,  we  have  the  following: 
L  >  0.149  meters 


With  this  tether  length,  we  would  have  a  gravity-gradient  torque  equal  to  the 
maximum  atmospheric  torque  we  would  expect,  namely:  3.714  x  10'7  Nm 

Figures  2-2  and  2-3,  below,  give  a  summary  of  the  atmospheric  and  gravity-gradient 
torques  that  DINO  would  experience  given  the  assumptions  laid  out  in  this 
document.  The  minimum  tether  length  due  to  atmospheric  disturbance  torques 
occurs  at  the  cross-over  point. 
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Figure  2-2 
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Figure  2-3 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  Univerisity  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1.3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

The  calculation  of  the  required  size  for  proper  magnetic  field  generation  and 
engineering  analysis  of  the  available  area  within  the  DINO  spacecraft  for  torque 
rods  is  described  in  this  document. 

1 .5  Referenced  Documents 

Makovec,  Kristin  L.:  A  Nonlinear  Magnetic  Controller  for  Three  Axis  Stability 
of  Nanosatellites;  Virginia  Polytechnic  Institute  and  State  University;  July  23, 
2001. 

Radtke,  Gregg:  Magnetic  Torquer  Overivew  Technical  Note;  University  of 
Arizona;  December  1,  1999. 

2  Background 

There  are  several  primary  industry  standards  used  to  control  spacecraft  attitude. 
These  methods  are  the  use  of  reaction  wheels,  propulsion  systems,  and  magnetic 
torque  devices.  Of  these  options  reaction  wheels  and  magnetic  torquers  were 
originally  studied  for  their  applicability  to  the  DINO  spacecraft.  Propulsion  systems 
were  not  considered  for  obvious  reasons,  primarily  safety  concerns.  Single  axis 
reaction  wheels  control  the  spacecraft’s  attitude  by  either  slowing  down  or  speeding 
up  their  rotation  rate  and  thereby  exerting  a  change  in  angular  momentum  of  the  s/c. 
The  main  performance  characteristics  of  reaction  wheels  are  their  ability  to  quickly 
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slew  the  s/c.  The  slew  rates  are  based  on  the  weight  of  the  wheel  and  its  rotation  rate. 
One  drawback  to  reaction  wheels  is  the  need  to  dump  stored  momentum  in  the  wheel 
as  the  rotation  rates  become  excessively  high.  This  energy  is  usually  released 
through  the  use  of  a  single  or  multiple  torque  rods.  The  second  control  actuator 
considered  was  a  magnetic  torque  rod.  These  are  either  wound  loops  of  wire  around 
air  or  around  a  ferromagnetic  material  such  as  iron.  By  passing  a  current  through  the 
loops  of  wire  a  magnetic  dipole  moment  is  produced.  The  moment  interacts  with  the 
Earth’s  magnetic  field  to  provide  a  torque  on  the  s/c.  Drawbacks  of  this  system  are 
the  weight  of  the  ferromagnetic  material  in  the  case  of  torque  rods  or  the  volume  of 
the  torque  coils.  By  weighing  the  benefits  and  disadvantages  of  each  system 
magnetic  torque  rods/coils  have  been  selected  as  the  primary  actuator.  The  greatest 
benefit  of  this  system  is  the  ability  to  design  and  construct  magnetic  torquers  at  the 
University  of  Colorado. 

3  Actuator  Requirements 

Several  requirements  may  be  placed  on  the  actuators  chosen  for  the  DINO  s/c.  The 
attitude  control  subsystem  has  been  initially  allotted  only  2.6  kg.  However,  project 
management  has  implied  that  as  much  as  4  kg  could  be  allotted  if  needed.  Secondly, 
the  subsystem  has  been  allotted  only  4W  for  nominal  operation.  The  4W  is  not  the 
maximum  power  usage  for  detumbling  of  the  s/c.  In  nominal  operation  the  control 
actuators  must  respond  to  disturbance  torques  by  the  environment  and  damp 
oscillations  caused  by  the  gravity  gradient  torques  induced  by  the  tethered  boom. 

3 . 1  Disturbance  T orques 

Several  environmental  factors  will  cause  disturbance  torques  during  orbit 
around  the  Earth.  These  factors  are  solar  radiation  pressure  from  the  sun, 
aerodynamic  drag  from  the  Earth,  and  gravity  gradient  forces  from  the  Earth. 
Since  DINO  will  utilize  a  gravity  gradient  tether  those  forces  will  not  be 
considered  as  a  disturbance  torque.  Early  analysis  of  solar  pressure  and  drag 
forces  discovered  a  maximum  disturbance  force  of  1.1  x  10'4  N  m.  This  assumes 
a  400km  altitude,  drag  coefficient  of  2.5  (sufficiently  high),  and  cross-sectional 
area  of  lm2.  Dividing  the  maximum  disturbance  torque  by  the  maximum 
magnetic  field  of  5x1 0‘5  Tesla  the  required  dipole  moment  output  of  the 
torquers  is  2.2  Am2.  However,  smaller  torquer  outputs  are  acceptable  with 
slower  recovery  rates.  Therefore,  the  minimum  torquer  output  shall  be 
considered  as  1  Am2  for  normal  operations. 

3.2  Detumbling 

Prior  to  deploying  the  gravity  gradient  tether  the  spacecraft  will  have  to  be 
stabilized  from  a  tumbling  state.  Exact  rotational  rates  of  the  initial  tumble  will 
be  unknown  and  may  be  relatively  fast.  Therefore,  the  minimum  torquer  output 
determined  above  will  not  be  sufficient  to  efficiently  detumble  the  s/c.  A  greater 
moment  on  the  order  of  10  to  20  Am2  would  be  desired  but  requires  much  too 
many  resources  in  power  and  weight.  The  recommendation  of  the  ADCS  team 
is  that  the  torquers  be  designed  to  output  the  greatest  possible  output  beyond  the 
minimum  of  1  .OAm2  that  is  allowable  per  overall  s/c  resources.  The  greater  the 
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output  produced  by  the  magnetic  torquers  the  faster  the  s/c  may  be  slowed  or 
slewed  to  another  orientation.  Specific  requirements  for  detumbling  of  the 
spacecraft  will  be  discussed  in  document  DINO-ADCS-RPT-DTUMBL.  This 
document  will  be  based  on  simulations  for  the  detumbling  of  the  s/c. 

4  Sizing  Analysis 


4.1  Torque  Coils 

Torque  coils  are  simply  wound  loops  of  wire,  commonly  copper  wire,  with 
current  passed  through.  The  current  flowing  in  the  loops  acts  similar  to  a 
solenoid  and  produces  a  magnetic  dipole  moment  shown  in  equation  4-1. 

M  =  IN  A 


Eq.  4-1 

In  equation  4-1, 1  is  the  input  current,  N  is  the  number  of  wire  loops,  and  A  is 
the  area  of  the  torque  coil.  The  torque  on  the  s/c  is  then  produced  by  the  cross 
product  of  the  magnetic  dipole  moment  and  the  Earth’s  magnetic  field  vector. 

T  =  MxB 

Eq.  4-2 

Early  studies  into  torque  coils  revealed  several  benefits.  They  produce  a  reliable 
and  easily  modeled  dipole  moment  output.  Early  studies  also  revealed  that  a 
torque  coil  producing  a  large  enough  output  would  require  a  large  volume.  The 
dimensions  of  the  coil  would  require  a  radius  of  near  6  inches.  This  large 
volume  is  a  major  drawback  to  the  consideration  of  using  torque  coils. 


4.2  Torque  Rods 

Torque  rods  behave  in  the  same  manner  as  torque  coils  except  they  utilize  the 
effect  of  a  ferromagnetic  rod  in  the  middle  of  the  wound  loops  of  wire.  A 
common  material  such  as  iron  has  a  magnetic  permeability  from  100  to  5000 
times  that  of  air.  Thus  magnifying  the  dipole  moment  output  from  the  loops  of 
wire  themselves.  The  major  drawback  to  this  system  is  the  heavy  weight  of  iron 
(density  of  4800  kg/m3  to  7874  kg/m3).  A  major  trade  study  has  been  conducted 
into  the  sizing  requirements  for  a  magnetic  torque  rod. 


Although  a  torque  rod  output  moment  of  2. 2 Am2  is  enough  to  counteract 
disturbance  forces  a  larger  torque  output  is  preferential.  Equation  3  shows  an 
estimate  of  the  required  slew  time  for  a  given  attitude  error. 


t  = 


2. 


J£_ 

MB 


Eq.  4-3 

In  equation  4-3, 13  is  the  moment  of  inertia  about  the  radial  direction,  theta  is  the 
initial  attitude  error,  M  is  the  maximum  torque  rod  dipole  moment  output,  and  B 
is  the  maximum  magnetic  field  strength'.  Figure  4-1  shows  the  relationship 
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between  the  dipole  moment  output  and  the  estimated  slew  times  for  an  initial 
position  error  of  2°  in  a  single  axis  perpendicular  to  the  magnetic  field. 


Slew  Time  as  a  Function  of  Torque  Rod  Moment 


Figure  4-1:  Slew  time  for  2  degree  error 

Due  to  the  exponential  form  of  the  relationship  it  is  more  desirable  to  produce  a 
maximum  torque  output  of  greater  5  Am2  to  stay  above  the  knee  in  the  curve. 


Obtaining  a  torque  output  moment  of  over  5  Am2  is  not  easy  with  the  weight 
and  power  limitations  put  on  the  system  by  the  s/c  design.  To  analyze  how  this 
may  be  accomplished  a  MATLAB  program  was  written  based  on  several 
primary  equations  of  power,  weight,  and  output. 

m  =  m2  ( Ni  +  IM) 


Eq.  4-4 

Where  m  is  the  torque  rod  output  moment,  r  is  the  radius  of  the  iron  core,  N  is 
the  number  of  wire  turns,  i  is  the  input  current,  1  is  the  torque  rod  length,  and  M 
is  the  magnetization  defined  by  M  =  B/po,  B  being  the  magnetic  field  strength 
and  po  being  the  permeability  of  air.  This  equation  allows  comparison  of  the 
output  moment  by  varying  the  torque  rod  radius  and  length.  Figure  4-2  shows 
the  relationship  between  the  physical  size  and  the  torque  rod  output  moment  for 
an  input  current  of  300mA  and  material  permeability  of  500. 
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Torque  Rod  size  vs.  Output  Moment 


Figure  4-2:  Sizing  chart  for  300mA  current  and  mu  =  500 


Figure  4-2  shows  an  output  moment  of  at  least  5  Am2  is  obtainable  at  an  input 
current  of  300mA.  Actually,  the  output  moment  is  very  obtainable  at  an  input 
current  of  only  150mA.  However,  the  torque  rod  size  required  to  obtain  the 
desired  moment  at  lower  currents  is  large  and  has  tremendous  weight  on  the 
order  of  several  kilograms  per  torque  rod.  Equation  5  shows  the  relationship 
between  the  weight  of  the  torque  rod  and  the  size. 

W  =  jzr2lp. 

r  iron 


Eq.  4-5 

Where  p  is  the  density  of  iron  equal  to  4800  kg/m3.  Figure  4-3  shows  the 
relationship  between  the  torque  rod  size  and  actual  weight. 
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Weight  of  Torque  Rod  vs.  Size 


Figure  4-3:  Torque  rod  weight  including  the  weight  of  the  wire 

Figure  4-3  shows  the  only  torque  rod  configuration  that  will  maintain  a  weight 
of  less  than  2  kg  for  all  three  torque  rods  is  of  a  long  rod  with  radius  of  14”  or 
3/8”.  Because  of  the  small  inner  radius  required  to  keep  the  torque  rods  within 
weight  constraints  the  input  current  must  be  the  before  mentioned  300mA  or 
larger.  Even  at  300mA  the  torque  rods  will  have  to  be  an  undesirable  length  of 
near  16  inches  each.  This  can  be  accomplished  by  placing  two  8  inch  rods  in 
each  axis.  This  may  require  a  more  complicated  control  algorithm  but  is 
necessary  in  order  to  detumble  the  spacecraft  upon  mission  start.  The  third 
concern  with  the  currently  suggested  configuration  is  power  concerns.  Figure  4 
shows  the  relationship  between  the  power  consumption  in  the  wire  around  the 
torque  rods. 
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Torque  Rod  Length  (in) 

Figure  4-4:  Power  consumption  of  torque  rod  for  24  gauge  wire 


Figure  4-4  shows  that  for  24  gauge  wire  with  a  long  torque  rod  and  at  most  3/8 
inch  radius  the  power  consumption  is  below  300mW.  This  low  power 
consumption  is  thus  not  a  design  concern.  The  maximum  power  usage  by  the 
torque  rods  will  be  while  detumbling  the  spacecraft.  After  this  time  the  torque 
rod  use  will  be  minimal  and  input  currents  may  be  kept  at  a  maximum  of 
150mA  minimizing  power  consumption  further. 

Due  to  the  strict  weight  requirements  and  desired  torque  rod  dipole  moment 
output  a  minimum  design  has  been  made.  The  torque  rods  shall  be  made  of  an 
iron  core  with  a  minimum  length  of  10  inches  and  inner  radius  of  3/8  inches. 
The  torque  rods  shall  be  wrapped  with  24  gauge  wire  with  an  input  current 
capable  of  300mA  for  detumbling  of  the  spacecraft.  This  configuration  is 
approximately  0.4kg  per  torque  rod  for  a  total  of  1 .2kg.  The  power  consumption 
is  minimal  at  200mW  per  torque  rod  at  maximum  output.  The  actual  torque  rod 
moment  output  for  this  design  is  3.0  Am2.  The  design  study  for  torque  rod 
output,  weight,  and  power  was  based  on  equation  found  in  reference  2. 
Furthermore,  iterative  analysis  beyond  the  graphs  presented  in  this  paper 
discovered  a  standard  ferrite  material  with  p  =  800.  This  material  is  easily 
obtained  and  thus  was  used  to  reproduce  the  graphs  presented. 


4.2.1  Design  Options 

The  previous  section  outlined  some  sizing  options  and  minimum 
requirements  based  on  several  design  decisions  that  have  not  been 
completed.  The  type  of  wire  used  in  the  design  significantly  alters  the 
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characteristics  of  the  torque  rod.  A  smaller  wire  such  as  30  gauge  is  smaller 
and  allows  more  turns  of  wire  for  the  same  length  of  torque  rod  creating  a 
larger  output.  The  larger  amount  of  wire  will  then  consume  significantly 
more  power  and  wire  temperature  may  also  become  a  concern.  Larger  wire 
will  consume  less  power,  but  have  a  small  torquer  output. 

The  actual  iron  used  will  alter  the  torquer  output.  An  iron  composition  with 
a  higher  magnetic  permeability  will  have  a  larger  torque  output.  The  design 
study  was  conducted  for  a  material  with  only  a  p  =  800  which  is  a  standard 
ferrite  material.  This  is  one  of  the  best  ways  to  improve  performance 
because  it  has  no  effect  on  other  design  decision,  it  simply  increases  output. 
Irons  with  higher  values  of  p  may  be  more  expensive.  Another  concern  with 
the  iron  is  finding  material  with  a  linear  hysterisis  curve.  This  means  the 
torque  rod  output  will  be  linear  with  increasing  current.  If  this  is  not  linear 
the  controller  theory  will  have  to  be  more  complex  to  account  for  the  non¬ 
linear  behavior.  Microcosm  or  Ithaco  may  be  able  to  provide  insight  as  to 
where  to  obtain  desirable  iron  cores. 

Another  design  decision  is  the  maximum  current  input  allowable.  The  more 
input  current  allowable  the  higher  the  output  moment  per  equation  4.  For 
detumbling  mode  it  may  be  possible  to  allow  even  more  than  300mA  to 
each  torque  rod.  If  this  were  the  case  the  design  may  be  made  smaller. 
Figure  5  shows  the  torque  rod  output  at  only  150mA. 


Torque  Rod  size  vs.  Output  Moment 


Figure  4-5:  Torque  Rod  output  for  150mA  input  current 
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The  figure  shows  for  a  10  in  torque  rod  and  a  1 50mA  input  current  an  output 
moment  of  1.5  Am2  may  be  obtained.  This  will  suffice  as  a  minimum 
requirement  for  normal  operations. 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  Univerisity  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1.4  Document  Overview 

Attitude  determination  and  control  has  the  primary  objective  of  maintaining  the 
spacecraft’s  orientation  in  order  to  obtain  scientific  data  defined  by  the  mission 
objectives.  The  primary  mission  objectives  for  the  Deployable  and  Intelligent 
Nanosatellite  Operations,  DINO,  satellite  are  mechanical  deployments  and 
stereoscopic  imaging  of  cloud  formations.  An  ADC  system  has  been  developed 
to  enable  these  objectives  to  be  met.  The  system  is  designed  to  provide  a 
nominal  orientation  for  deployment  of  first  a  gravity-gradient  tethered  boom 
followed  by  deployments  of  FITS  and  the  CTD  panel.  The  FITS  and  CTD 
panel  consist  of  a  secondary  solar  array  and  a  sensor  package,  not  attitude 
control  devices.  The  system  will  then  provide  passive  control  in  the  roll  and 
pitch  axes  through  gravity-gradient  stabilization  and  yaw  control  through  a 
feedback  control  system.  While  the  system  will  only  be  used  for  yaw  control  in 
nominal  operations  it  has  been  designed  to  provide  three-axis  control  for  s/c 
detumbling  after  mission  start,  prior  to  the  deployment  of  the  gravity-gradient 
tether. 

The  ADC  system  has  been  designed  to  provide  a  simple  and  effective  means  of 
controlling  s/c  attitude  to  meet  mission  objectives.  The  system  will  consist  of  a 
magnetometer  for  measurement  of  the  local  magnetic  field  and  three  single-axis 
rate  gyroscopes  for  measurement  of  the  s/c  rotational  rates.  These  devices  will 
be  used  with  an  onboard  orbit  propagator  and  magnetic  field  model  yielding  the 
expected  local  magnetic  field.  The  attitude  will  be  determined  through  software 
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algorithms  comparing  the  local  sensed  magnetic  field  and  expected  magnetic 
field  and  directly  incorporating  the  s/c  rotation  rates.  The  attitude  will  then  be 
controlled  by  magnetic  torque  rods  exerting  a  magnetic  dipole  moment  that 
interacts  with  the  Earth’s  magnetic  field  to  provide  a  torque  on  the  s/c.  The 
torque  rods  will  be  controlled  by  electronics  on  the  ADCS  interface  board 
which  in  turn  are  controlled  by  the  software  control  algorithm. 


1 .5  Referenced  Documents 

Honeywell  HMC2003  Datasheet 

Analog  Devices  ADXRS150EB  Datasheet 

DINO-ADCS-DWG-SCBD 1 

DINO-ADCS-DWG-SCBD2 

DINO-ADCS-DWG-SCBD3 

DINO-ADCS-DWG-SCBD4 

DINO-ADCS-DWG-SCBD5 

DINO-ADCS-DWG-SCBD6 

DINO-ADCS-ASM-TORROD 

DINO-ADCS-RPT-MAG 


2  Sensors 

The  sensors  associated  with  the  attitude  determination  are  the  Honeywell  HMC2003 
Magnetometer  and  the  Analog  Devices  ADXRS150EB  Rate  Gyroscope. 

2.1  Honeywell  HMC2003  Magnetometer 

The  Honeywell  magnetometer  provides  local  magnetic  field  sensing  data.  The 
output  of  the  magnetometer  is  three  0.5  -  4.5V  analog  signals  for  the  x,y,  and  z 
components  of  the  magnetic  field.  These  components  will  be  used  in  attitude 
determination  and  also  to  provide  the  optimal  control  of  the  magnetic  torque 
rods  for  interaction  with  Earth’s  magnetic  field  sensed  by  the  magnetometer.  All 
other  specifications  for  the  Honeywell  HMC2003  Magnetometer  are  shown  in 
the  referenced  datasheet. 

Due  to  the  magnetometer’s  sensitivity  to  local  magnetic  fields  it  shall  be 
isolated  from  other  electronic  equipment.  For  this  reason  it  will  not  be  located 
on  the  attitude  board  with  the  rest  of  the  electronic  components  of  the  system. 
Figure  2-1  shows  the  electrical  interface  with  the  magnetometer  that  shall  be 
built  onto  a  small  circuit  board. 
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The  Honeywell  magnetometer  provides  output  for  field  ranges  of  +/-  2  Gauss. 
However,  this  is  significantly  greater  than  the  field  that  shall  be  sensed  in  flight. 
The  maximum  magnetic  field  of  the  Earth  is  near  0.3  Gauss  in  either  the  positive 
or  negative  direction  depending  on  the  orientation  of  the  s/c.  Therefore,  a 
conditioning  circuit  has  been  built  to  focus  on  the  output  from  2V  to  3V, 
corresponding  to  a  field  range  of  +/-  0.5  Gauss  from  null  field.  With  the  A/D 
converters  in  ADC  system  the  accuracy  of  the  magnetometer  becomes 
244pGauss. 


2.2  Analog  Devices  ADXRS150  Rate  Gyroscope 

The  Analog  Devices  rate  gyroscope  provides  rotation  rate  measurements  along 
the  z-axis  of  the  IC  chip.  Therefore,  three  of  these  single-axis  rate  gyros  are 
placed  in  an  orthogonal  alignment  to  provide  full  three-axis  rate  information. 
These  sensors  shall  be  placed  on  the  attitude  board  discussed  in  detail  later  in 
the  manual.  The  resolution  of  the  gyro  has  been  tested  up  to  0.0047s  by  the 
manufacturer.  The  output  of  each  rate  gyro  chip  is  a  0.25V  -  4.75V  analog 
output  that  is  converted  to  digital  data  on  the  interface  board.  The  rate  data  is 
directly  used  by  the  attitude  determination  algorithms  as  s/c  rates.  All  other 
specifications  for  the  Analog  Devices  ADXRS150EB  Rate  Gyroscope  are 
provided  in  the  referenced  datasheet. 
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As  with  the  magnetometer  the  rate  gyro  provides  output  ranges  much  greater 
than  needed  for  the  system.  To  provide  higher  accuracy  results  a  conditioning 
circuit  has  been  designed  to  focus  on  the  rate  gyro  output  between  1.75V-3.25V. 
This  yields  a  rotation  range  of  +/-  60°/s.  With  the  1 2-bit  A/D  converters  used  by 
ADC  system  interface  board  the  accuracy  of  the  rate  gyros  are  0.02937s. 

3  Actuators 

The  only  actuators  associated  with  the  ADC  system  are  three  single-axis  magnetic 
torque  rods.  The  magnetic  torque  rods  provide  continuous  two-axis  control  and 
periodic  three-axis  control.  A  full  discussion  of  the  magnetic  torque  rods  is  included 
in  this  section. 

3.1  Magnetic  Torque  Rod 

A  separate  document  titled  DINO-ADCS-RPT-TQSIZE  outlines  the  methods 
used  to  design  the  magnetic  torque  rods.  A  final  design  was  selected  based  on  a 
large  trade  study,  material  availability,  and  analytical  analysis.  The  magnetic 
torque  rods  will  be  built  using  a  manganese  zinc  core  with  a  magnetic 
permeability  of  800.  The  density  of  the  material  is  much  less  than  that  of  iron. 
The  cores  are  wrapped  in  28AWG  magnet  wire.  The  torque  rods  will  simply 
have  an  input  of  two  power  lines.  The  torque  rod  control  circuitry  will  vary  the 
amount  and  direction  of  current  through  the  torque  rods  to  vary  the  magnetic 
field  produced  by  the  torque  rods. 

The  design  calls  for  three  torque  rods  in  an  orthogonal  reference  frame.  The 
torque  rods  are  placed  in  the  s/c  at  locations  most  convenient  for  the  structural 
layout  of  the  s/c  and  to  isolate  them  as  much  as  possible  from  electrical 
equipment.  They  are  placed  in  the  s/c  such  that  the  ends  of  the  torque  rods  are  at 
the  sides  of  the  s/c.  This  will  force  the  largest  magnetic  fields  emanating  from 
the  torque  rods  outside  of  the  s/c  rather  than  into  sensitive  electronic  equipment. 
The  torque  rods  are  built  to  the  specifications  of  a  approximately  12”  length 
with  Vj"  diameter.  The  effects  upon  circuitry  within  the  DINO  spacecraft  was 
functionally  tested  by  applying  500mA  (160%  of  maximum  current)  to  the 
torque  rods  with  the  flight  computer,  camera’s,  radios,  and  ADC  systems 
running  within  1”  of  the  torque  rods.  This  configuration  did  not  effect  the 
operation  of  these  circuits;  therefore,  the  placement  of  the  torque  rods  within  the 
spacecraft  is  dependant  upon  the  magnetometer  only. 

4  ADCS  Box 

The  ADCS  Box  will  be  the  primary  center  for  electronics  associated  with  the  ADC 
system.  The  ADC  system  contains  circuits  for  the  magnetometer,  rate  gyros,  and 
torque  rod  control.  The  ADCS  Box  will  contain  all  the  electrical  circuits  and  sensors 
except  that  of  the  magnetometer.  The  magnetometer  is  isolated  away  from  other 
electronics. 


Page  7  of  13 


25  of  190 


DINO:  Complete  Title 


DINO-SUBSYS-TYPE-TITILE,  Rev.  A 


* 


4.1  Rate  Gyro 

4.1.1  Circuit  Design 

The  analog  devices  rate  gyros  are  supplied  in  an  easy  to  integrate 
evaluation  board  package.  The  package  has  20  pins  connected  inline. 
Error!  Reference  source  not  found.  1  shows  the  circuit  design  for 
connection  of  the  rate  gyros. 


The  range  of  the  raw  rate  gyro  output  with  0.0047s  of  resolution  allows 
for  75,000  points  of  discrete  intervals.  A  12-bit  analog  to  digital  (A/D) 
conversion  allows  4096  discrete  intervals  which  greatly  reduces  the 
possible  resolution,  thereby,  reducing  the  sensing  capability  of  the 
ADCS  system.  The  expected  rates  in  an  orbit  are  highest  at  release  from 
the  launch  vehicle  and  will  most  likely  be  less  than  107s.  Reducing  the 
range  of  the  output  to  ±607s  will  allow  for  a  higher  resolution  in  the 
A/D  conversion.  The  number  of  discrete  intervals  for  maximum 
resolution  is  reduced  to  30,000  which  are  not  within  the  range  of  a  12-bit 
signal,  but  does  allow  for  much  higher  resolution  of  0.02937s.  The 
signal  conditioning  was  designed  such  that  a  change  in  orbit 
requirements  would  allow  for  a  change  in  the  output  of  the  rate  gyro 
circuitry.  This  would  be  accomplished  by  changing  the  resistance  values 
within  the  signal  conditioning  circuitry.  The  following  equations  (Eq.  4- 
1  thru  4-5)  are  utilized  to  perform  the  resistance  calculations. 


Vou,  =  *3 


Li 

R, 


_5 

R 


2  J 


Ra 


Eq.  4-1 
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°'"  Ra 


V;_  -■ 


5 


R 


2  J 


.  5V  .  , 
/,  =  —  +  4mA 
R2 


R0  = 


5V-12V 


Eq.  4-2 


Eq.  4-3 


Eq.  4-4 


R,=R3 

Eq.  4-5 


Table  4-1  allows  the  resistances  in  the  equations  to  be  correlated  to  the 
resistors  in  the  actual  circuitry  for  the  magnetometer  as  depicted  in  the 
schematic  DINO-ADCS-DWG-SCBD2 


Table  4-1:  Rate  Gyro  Resistor  Matrix 


Equation 

Nomenclature 

Circuit 

Nomenclature 

Current  Resistance 
Value 

Ro 

R21,  R27,  R33 

1.6K 

Ri 

R22,  R28)  R34 

5.6K 

r2 

R23,  R29,  R35 

16K 

r3 

R24,  R30>  R36 

5.6K 

R4 

R25,  R31,  R37 

3K 

r5 

R26;  R32,  R38 

10K 

4.1.2  Testing 

The  rate  gyro  circuitry  was  constructed  on  a  “prototyping  board”  with 
the  corresponding  components.  A  voltmeter  was  placed  in  the  output  of 
the  circuit.  Variable  power  supplies  were  utilized  to  simulate  the  input 
voltages  of  the  +12VDC,  -12VDC,  and  +5VDC  power  supplies.  The 
circuit  was  then  rotated  in  each  direction  to  verify  correct  response  of 
the  rate  gyro.  The  rate  gyro  was  also  verified  to  have  insignificant  drift 
by  placing  it  in  a  stable  atmosphere  (i.e.  not  rotating)  and  taking  data  for 
48  hours.  The  following  figure,  Figure  4-2  displays  the  results  of  this 
test. 
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2.468 


2.448  -I - , - , - t - 1 - , - , - , - 1 

0  5  10  15  20  25  30  35  40  45 

Time  (hours) 


Figure  4-2:  Rate  Gyro  48hr  Test  Results 

The  rate  gyro  had  no  drift  when  average  value  of  the  output  is  taken. 
The  null  rate  is  approximately  2.5VDC  and  will  have  to  be  taken  from 
the  individual  rate  gyros  before  launch  to  verify  the  values  in  software. 
This  value  will  also  be  affected  by  the  signal  conditioning  circuitry.  The 
circuits  were  tested  individually  in  the  same  manner  after  they  were 
manufactured  and  populated.  After  testing,  the  circuits  were 
functionally  tested  with  the  completed  ADCS  electronics  hardware 
which  is  addressed  in  later  sections  of  this  document. 

4.2  Torque  Rod  Current  Control 

4.2.1  Circuit  Design 

Several  requirements  are  placed  upon  the  attitude  electronics  by  the 
torque  rods. 

1 .  The  input  current  must  be  supplied  in  proportional  control 
between  0-300mA. 

2.  The  input  current  must  be  capable  of  being  supplied  in  either 
direction  through  the  torque  rod. 

3.  The  amount  and  direction  of  current  must  be  capable  of  being 
controlled  by  the  flight  computer. 

These  requirements  led  to  a  design  shown  in  Error!  Reference  source 
not  found..  The  input  to  the  control  circuit  is  an  analog  voltage  and  a 
directional  signal.  These  signals  shall  be  supplied  through  a  Texas 
Instruments  DAC8574  D/A  converter  from  the  flight  computer. 
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The  methodology  of  this  circuit  is  fairly  simple.  The  amount  of  current 
to  the  torque  rod  may  be  controlled  by  varying  the  input  current  (V=IR). 
Since  there  is  a  set  resistance  in  the  Rbias  and  the  torque  rod,  I=V/R. 
Thus,  a  digital  signal  from  the  flight  computer  to  a  D/A  can  supply  an 
output  voltage.  The  output  voltage  is  amplified  through  the  op-amp  and 
thereby  supplies  the  desired  current  to  the  torque  rods.  The  direction  of 
current  is  controlled  through  the  switching  MOSFET’s.  By  sending  a 
TTL  high/low  one  of  two  things  occurs.  Either  both  switches  Q12  and 
Q14  are  closed  or  both  switches  Q13  and  Q15  are  closed.  When  Q12 
and  Q14  are  closed  the  current  flows  in  a  positive  direction  and  when 
Q13  and  Q15  are  closed  current  flows  in  the  negative  direction.  The 
gates  are  controlled  by  the  high/low  input  to  an  inverting/non  inverting 
amplifier. 

4.2.2  Testing 

The  torque  rod  control  circuitry  was  constructed  on  a  “prototyping 
board”  with  the  corresponding  components.  An  ammeter  replaced  the 
torque  rod  in  the  output  of  the  circuit.  Variable  power  supplies  were 
utilized  to  simulate  the  input  voltages  of  the  +12VDC,  -12VDC,  and 
+5VDC  power  supplies.  An  additional  variable  power  supply  was  then 
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utilized  to  simulate  the  input  voltage  from  the  flight  computer  to  control 
the  torque  rod  current  output.  The  directional  input  was  simulated  by 
connecting  to  ground  and  +5VDC  on  the  +5VDC  power  supply.  This 
test  was  successful  and  yielded  the  expected  results  of  0-300mA  for  a  0- 
5VDC  input  and  the  current  direction  changed  with  respect  to  the 
directional  input.  The  circuits  were  tested  individually  in  the  same 
manner  after  they  were  manufactured  and  populated.  After  testing,  the 
circuits  were  functionally  tested  with  the  completed  ADCS  electronics 
hardware  which  is  addressed  in  later  sections  of  this  document. 

4.3  Digital  Conversion 

The  ADC  system  contains  analog  to  digital  and  digital  to  analog  conversion 
hardware  which  will  enable  the  flight  computer  to  access  information  from  the 
sensors  and  control  the  actuators  from  an  isolated  I2C  bus. 

4.3.1  Analog  to  Digital  Conversion 

The  analog  to  digital  (A/D)  conversion  will  be  accomplished  by  the 
Texas  Instruments  ADS7828  A/D  converter.  This  is  a  12-bit  converter 
with  an  I2C  interface  and  capable  of  accepting  8  analog  inputs.  There 
are  2  ADS7828  chips  in  the  ADCS  Box  which  accept  the  rate  gyro, 
torque  rod  current  feedback,  and  magnetometer  inputs.  The 
magnetometer  inputs  are  separated  onto  the  second  ADS7828  to  enable 
it  to  be  transferred  into  the  Magnetometer  Box  if  future  testing  reveals 
large  noise  spikes  on  the  magnetometer  analog  lines  from  the 
Magnetometer  Box  to  the  ADCS  Box.  Each  of  the  ADS7828  has  the 
capability  to  have  4  addresses  on  the  I2C  bus  enabling  one  I2C  bus  to  be 
utilized,  minimizing  the  amount  of  interface  wiring  required  between  the 
ADC  and  C&DH  systems. 

4.3.2  Digital  to  Analog  Conversion 

The  digital  to  analog  (D/A)  conversion  will  be  accomplished  by  the 
Texas  Instruments  DAC8574  D/A  converter.  This  is  a  16-bit  converter 
with  an  I2C  interface  and  capable  of  converting  4  analog  outputs.  There 
are  2  DAC8574  chips  in  the  ADCS  Box  which  output  the  torque  rod 
current  amount,  torque  rod  current  direction,  and  magnetometer  reset 
signal.  The  DAC8574’s  each  has  the  capability  of  4  I2C  addresses 
which  do  not  correspond  to  the  addresses  of  the  ADS7828.  This  enables 
the  two  ADS7828  and  the  two  DAC8574  to  be  on  the  same  I2C  bus, 
further  minimizing  the  interface  wiring  between  the  ADC  and  C&DH 
systems. 

4.3.3  Conversion  Testing 

Each  of  the  A/D  and  D/A  converters  was  tested  individually  with  the 
flight  computer  through  testing  software.  The  software  was  able  to 
access  the  converters  and  vary  the  outputs  on  the  D/A  converter  and 
sense  changes  in  input  for  the  A/D  converter.  The  original  A/D 
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converter,  ADS1 112,  was  also  tested  individually.  This  A/D  converter 
had  addressing  which  corresponded  to  the  addressing  of  the  DAC8574, 
but  had  the  ability  to  have  8  addresses.  During  functional  testing  of  the 
conversion  board  it  was  found  that  the  ADS1 1 12  was  not  able  to  handle 
3  inputs  per  chip  from  0-5V  as  originally  thought.  The  ADS1 1 12  was 
able  to  handle  2  inputs  from  0-5 V  and  3  inputs  from  0-2 V;  therefore,  a 
design  change  was  made  to  the  ADS7828,  which  can  handle  up  to  8 
inputs  from  0  to  5  V.  The  tradeoff  was  that  the  ADS1 1 12  is  a  16-bit 
converter  whereas  the  ADS7828  is  a  12-bit  converter.  The  ADC  system 
has  since  been  tested  as  a  complete  unit  and  is  explained  in  further 
sections  of  this  document. 

5  ADC  System  Integration 

The  ADCS  electronics  within  the  ADCS  Box  were  integrated  after  individually 
testing  each  section  of  the  ADC  system.  The  magnetometer  electronics  were  then 
integrated  with  the  ADCS  electronics  to  ensure  the  entire  ADC  system  operated 
properly  prior  to  integration  into  the  DINO  electronics. 

5.1  Testing 

The  ADCS  electronics  were  tested  as  a  unit  with  testing  software.  The  software 
was  an  open  loop  system  which  allowed  the  testing  operators  to  change  current 
and  direction  of  the  torque  rods.  The  output  of  the  rate  gyros  and  torque  rod 
current  feedback  were  verified  to  be  correct.  The  testing  replaced  the  torque 
rods  with  an  ammeter  in  the  same  fashion  as  the  individual  testing  of  the  torque 
rod  control  circuit.  All  testing  involved  the  connectors  for  the  wiring  harness  to 
ensure  continuity  of  the  system.  The  functional  test  verified  the  torque  rod 
current  could  be  controlled  through  software  and  that  the  flight  computer  would 
be  able  to  take  readings  from  the  rate  gyros  and  magnetometer. 
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1  Scope 

1 . 1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  Univerisity  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

The  magnetometers  were  tested  with  the  torque  rods  to  examine  the  effect  of  the 
torque  rods  on  the  sensing  ability  of  the  magnetometer.  Research  into  the 
effects  of  magnetic  material  on  magnetometer  operation  revealed  that  the 
magnetometer  should  be  placed  a  minimum  of  12in  from  any  magnetic  device. 
This  configuration  is  not  possible  with  the  DINO  spacecraft;  therefore,  testing 
was  needed  to  examine  the  effect  of  the  torque  rods  on  the  magnetometer  for 
placement  of  the  torque  rods  and  magnetometer  in  the  spacecraft.  This 
document  describes  the  procedures  used  for  testing  including  results  and 
analysis.  A  requirement  for  placement  of  the  torque  rods  9in  away  from  the 
magnetometer  was  created  from  this  testing.  The  magnetometer  signal  is 
conditioned  to  increase  the  resolution  of  the  circuitry  to  that  of  the  actual 
sensing  device.  The  correlation  of  this  signal  to  Earth’s  magnetic  field  is  then 
utilized  for  attitude  sensing. 

1 .5  Referenced  Documents 

HMC2003  Magnetometer  Datasheet 
DINO-ADCS-PROC-MAGTST 
AFRL  Internal  Cargo  Unit  Users  Guide 
DINO-ADCS-DWG-SCBD1 
DINO-ADCS-DWG-BLBD 1 
Geopack-2003 
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NPSAT1  Magnetic  Attitude  Control  System 
Spacetrack  Report  No.  3 

2  Magnetometer  Testing  with  Torque  Rods  OFF 
2.1  Setup  and  Procedure 

The  magnetometer  and  torque  rods  were  setup  per  DINO-ADCS-PROC- 
MAGTST.  The  outputs  were  saved  in  a  Microsoft  Excel  format  for  data 
analysis. 


2.2  Results 

The  following  figures  and  tables  (figure  2-1,  2,  &  3  and  table  2-1,  2,  &  3)  graph 
the  average  output  of  the  magnetometer  over  a  period  of  0.5-2  seconds  for  each 
test:  X,  Y,  Z. 


No  Power  Torque  Rods  X-Axis 


4.5 

4.4 

4.3 

4.2 

4.1 
4 

3.9 

3.8 

3.7 

3.6 

3.5 

3.4 

3.3 

3.2 
3.1 

3 

2.9 

2.8 

2.7 

2.6 

2.5 


13  6  9 


Inches  from  Magnetometer 


-*■ 


-9 


12  15 


-*-X 
•  Y 
Z 

Z  Initial 
Y  Initial 
X  Initial 


Figure  2-1:  Torque  Rod  in  X-Axis 


Torque  Rod  in  X-Axis 


Inches 

1 

3 

6 

9 

12 

15 


X 

4.402052 

4.352215 

4.318976 

4.333718 

4.333333 

4.331118 


Table  2-1: 
Y 

3.35285 

3.196078 

3.095682 

3.058824 

3.041394 

3.039326 


Z 

4.220316 

4.215541 

4.223722 

4.225298 

4.22358 

4.217791 


Z  Initial 

4.209123 

4.209123 

4.209123 

4.209123 

4.209123 

4.209123 


Y  Initial 

3.027012 

3.027012 

3.027012 

3.027012 

3.027012 

3.027012 


X  Initial 

4.296351 

4.296351 

4.296351 

4.296351 

4.296351 

4.296351 
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Table  2-2:  Torque  Rod  in  Y-Axis 


Inches 

X 

y 

z 

x-initial 

y-initial 

z-initial 

1 

3.251946 

3.418341 

4.033967 

3.691477 

3.725624 

4.078165 

3 

3.54902 

3.627451 

4.094268 

3.691477 

3.725624 

4.078165 

6 

3.6257 

3.707866 

4.107026 

3.691477 

3.725624 

4.078165 

9 

3.67224 

3.726286 

4.11277 

3.691477 

3.725624 

4.078165 

12 

3.686084 

3.725681 

4.109842 

3.691477 

3.725624 

4.078165 

15 

3.689387 

3.726424 

4.099129 

3.691477 

3.725624 

4.078165 
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No  Power  Torque  Rod  Z-Axis 


5 

4.8 

4.6 

4.4 

4.2 
4 

3.8 

3.6 

3.4 

3.2 
3 

2.8 

2.6 

2.4 

2.2 
2 


J 


1  3  6  9  12  15 


Inches  from  Magnetometer 


Figure  2-3:  Torque  Rod  in  Z-Axis 


Table  2-3:  Torque  Rod  in  Z-Axis 


X 

y 

z 

x-initial 

y-initial 

z-initial 

1 

2.697965 

3.572819 

2.38885 

3.731575 

3.744591 

4.137931 

3 

3.366149 

3.731073 

3.801471 

3.731575 

3.744591 

4.137931 

6 

3.580599 

3.748269 

3.120624 

3.731575 

3.744591 

4.137931 

9 

3.680822 

3.745937 

4.13348 

3.731575 

3.744591 

4.137931 

12 

3.708483 

3.746699 

4.141056 

3.731575 

3.744591 

4.137931 

15 

3.725267 

3.744764 

4.143717 

3.731575 

3.744591 

4.137931 

The  effects  of  the  un-powered  torque  rod  on  the  magnetometer’s  output  do  not 
become  apparent  until  the  torque  rod  is  9  inches  from  the  magnetometer.  This 
observation  leads  to  a  requirement  where  the  torque  rods  must  be  placed  a 
minimum  of  9  inches  from  the  magnetometer. 

3  Magnetometer  Testing  with  Torque  Rods  ON 

3.1  Setup  and  Procedure 

The  magnetometer  and  torque  rods  were  setup  per  DINO-ADCS-PROC- 
MAGTST.  The  outputs  were  saved  in  a  Microsoft  Excel  format  for  data 
analysis. 
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3.2  Results 

The  following  figures  and  tables  (figure  3-1  &  2  and  table  3-1  &  2)  graph  the 
average  output  of  the  magnetometer  over  a  period  of  0.5-2  seconds  for  each 
test:  X  &  Y. 


Powered  T orque  Rod  X-Axis 


— X 

— ■ —  y 
Z 

x-initial 
— *—  y-initial 
— • —  z-initial 


Inches  From  Magnetometer 


Figure  3-1:  Torque  Rod  in  X-Axis 


Torque  Rod  in  X-Axis 


Inches 

1 

3 

4 

5 

6 
9 

12 

15 


x 

0 

0 

0 

1.019876 

2.297013 

3.04504 

3.324673 

3.255508 


Table  3-1: 

y 

o 

o 

o 

o 

0.371365 

1.549117 

2.123203 

2.37265 


0 

0 

0 

0 

0.457297 

1.56591 

2.158333 

2.390237 


x-initial 

3.300135 

3.300135 

3.300135 

3.300135 

3.300135 

3.300135 

3.300135 

3.300135 


y-initial 

2.646748 

2.646748 

2.646748 

2.646748 

2.646748 

2.646748 

2.646748 

2.646748 


z-initial 

2.73213 

2.73213 

2.73213 

2.73213 

2.73213 

2.73213 

2.73213 

2.73213 
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Figure  3-2:  Torque  Rod  in  Y-Axis 


Table  3-2:  Torque  Rod  in  Y-Axis 


Inches 

X 

y 

z 

x-initial 

y-initial 

z-initial 

3 

5 

0.801879 

5 

4.119786 

3.155674 

3.240404 

6 

5 

2.367195 

5 

4.119786 

3.155674 

3.240404 

9 

5 

2.982353 

5 

4.119786 

3.155674 

3.240404 

10 

2.707701 

2.927419 

2.978495 

4.119786 

3.155674 

3.240404 

11 

2.734559 

2.873652 

2.855882 

4.119786 

3.155674 

3.240404 

12 

4.931373 

3.171443 

3.269859 

4.119786 

3.155674 

3.240404 

15 

4.559971 

3.192144 

3.292609 

4.119786 

3.155674 

3.240404 

The  magnetometer  became  saturated  in  the  X  and  Y  Axes  very  quickly  which  is 
seen  in  the  figures  and  tables  above.  The  effect  of  the  powered  torque  rods  is 
extremely  detrimental  to  the  ability  of  the  magnetometer  to  detect  accurately. 
This  factor  will  require  the  software  to  ignore  readings  from  the  magnetometer 
during  torque  rod  operation,  effectively  setting  a  duty  cycle  requirement  for  the 
torque  rods.  The  Z-Axis  was  not  tested  due  to  time  requirements  and  the 
expected  results  being  confirmed  by  the  X-axis  and  Y-axis  tests,  therefore,  the  Z- 
axis  was  not  required. 

4  Magnetometer  Operation 

4.1  Magnetometer  Output 
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4.1.1  Raw  Output 

The  Honeywell  HMC2003  magnetometer  outputs  in  3-axes.  The  output 
is  a  range  of  0.5-4.5VDC  which  corresponds  to  ±2  gauss.  The  resolution 
of  the  magnetometer  is  40pgauss  with  a  field  sensitivity  of  lV/gauss. 

4.1.2  Signal  Conditioning 

The  range  of  the  raw  magnetometer  output  with  40pgauss  of  resolution 
allows  for  100,000  points  of  discrete  intervals.  A  12-bit  analog  to  digital 
(A/D)  conversion  allows  4096  discrete  intervals  which  do  not  give  the 
highest  resolution  possible,  thereby,  reducing  the  sensing  capability  of 
the  ADCS  system.  The  expected  field  in  an  orbit,  which  conforms  to  the 
specifications  given  in  the  AFRL  Internal  Cargo  Unit  Users  Guide 
section  4.1,  is  within  ±0.5gauss  allowing  for  the  signal  to  be  amplified 
prior  to  A/D  conversion.  This  reduces  the  number  of  discrete  intervals 
for  maximum  resolution  to  25,000  which  is  not  within  the  range  of  a  12- 
bit  signal,  but  greatly  increases  the  resolution  of  the  final  signal  to 
244pgauss.  The  signal  conditioning  was  designed  such  that  a  change  in 
orbit  requirements  would  allow  for  a  change  in  the  output  of  the 
magnetometer  circuitry.  This  would  be  accomplished  by  changing  the 
resistance  values  within  the  signal  conditioning  circuitry.  The  following 
equations  (Eq.  4-1  thru  4-5)  are  utilized  to  perform  the  resistance 
calculations. 


Vm  =  *3 


K ,__A 

v*.  *2  7 


*5 

R* 


V  =  — 

~  r4 


v.  -**>- 


R 


2  7 


1 2  =  — —  +  4mA 
R2 


*o  = 


5V -\2V 


Eq.  4-1 


Eq.  4-2 


Eq.  4-3 


*.=*3 


Eq.  4-4 


Eq.  4-5 

Table  4-1  allows  the  resistances  in  the  equations  to  be  correlated  to  the 
resistors  in  the  actual  circuitry  for  the  magnetometer  as  depicted  in  the 
schematic  DINO-ADCS-DWG-SCBD1 
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Table  4-1:  Magnetometer  Resistor  Matrix 


Equation 

Circuit 

Current  Resistance 

Nomenclature 

Nomenclature 

Value 

Ro 

R3,  R9,  R]5 

1.2K 

R> 

R4,  Rio,  R16 

1.2K 

r2 

R5,  Rn,  Rl7 

3K 

r3 

R6,  R12,  Rl8 

1.2K 

R4 

R7,  R.3,  Rl9 

1.5K 

r5 

Rg,  Rm,  R20 

7.5K 

4.2  Magnetometer  Attitude  Sensing 

4.2.1  Orbit  Propagation  and  B-Field 

In  order  to  properly  sense  the  attitude  of  DINO  within  the  orbit  the 
spacecraft  must  know  its  location  and  the  magnetic  field  in  that  location. 
The  obit  propagator  used  on  the  spacecraft  is  the  SGP4  obit  propagation 
software.  The  3-axis  sensing  of  the  magnetometer  allows  a  vector  the  B- 
field  of  the  Earth  to  be  sensed.  Geopack  2003  then  can  be  utilized  with 
the  orbit  propagator  to  compare  the  actual  B-field  vector  with  the 
expected  B-field  vector  to  create  an  attitude  error.  Testing  of  this 
software  architecture  was  researched  in  the  referenced  documentation. 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

This  document  describes  all  the  hardware  of  the  Command  and  Data  Handling 
subsystem. 

1 .5  Referenced  Documents 

Command  and  Data  Handling  Interface  Board  -  DINO-CDH-RPT-INTBRD 
Command  and  Data  Handling  USB  Hub  -  DINO-CDH-RPT-HUB 
Command  and  Data  Handling  Flight  Computer  -  DINO-CDH-RPT-FCOMP 
Command  and  Data  Handling  Wiring  Details  -  DINO-CDH-RPT- WIRING 


2  System  Description 

The  command  and  data  handling  subsystem  is  responsible  for  storing  and  running  all 
of  the  spacecraft's  software  and  controlling  all  of  the  other  subsystems. 


3  Interfaces 

Full  details  for  internal  wiring  and  connections  to  the  wiring  harness  are  in  the 
Command  and  Data  Handling  Wiring  Details  (DINO-CDH-RPT- WIRING) 
document. 

3.1  Connections  to  Power  System 

•  RS-422  to  send  commands/receive  status 
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•  digital  output  to  watchdog  timer  on  power  board 

•  4  analog  inputs  from  battery  thermal  sensors 

•  5V  C&DH  power  provided  by  power  board 

3.2  Connections  to  Tip  Mass 

•  RS-232  serial  connection 

3.3  Connections  to  Communication  System 

•  RS-232  serial  to  transmit  radio 

•  RS-232  serial  to  receive  radio 

•  USB  to  TNC  microcontroller 

3.4  Connections  to  Thermal  Sensors 

•  4  I2C  buses 

3.5  Connections  to  Mechanisms 

•  I2C  bus 

•  5  digital  inputs  to  monitor  deployment  status 

3.6  Connections  to  Science 

•  2  USB  cameras 

3.7  Connections  to  Attitude  Determination  and  Control 

•  I2C  bus 

4  Hardware 

4 . 1  Flight  Computer 

The  flight  computer  is  a  PC/ 104  form  factor  single  board  computer  based  on  the 
Intel  Xscale  CPU.  Implementations  of  the  C&DH  system  are  being  tested  using 
2  different  computers:  the  Arcom  Viper  and  the  Arcom  Mercury.  More  details 
on  these  2  computers  are  in  the  Command  and  Data  Handling  Flight  Computer 
(DINO-CDH-RPT -FCOMP)  document. 

4.1.1  Arcom  Viper 

The  Viper  was  the  first  choice  for  the  flight  computer  before  the 
Mercury  became  available  and  has  been  used  in  developing  hardware 
and  software  for  the  C&DH  system.  Because  this  computer  has  only  2 
USB  ports,  the  use  of  a  USB  hub  will  necessary  to  connect  the  Viper  to 
the  4  USB  devices  used  in  the  satellite. 

4.1.2  Arcom  Mercury 

The  Mercury  is  a  new  computer  from  Arcom  that  features  a  faster  CPU 
and  some  upgraded  I/O  options.  It  has  4  USB  ports,  so  the  USB  hub  is 
not  needed  if  this  computer  is  used  in  the  C&DH  system.  This  computer 
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is  the  preferred  choice  for  the  mission  and  will  be  used  if  it  succeeds  in 
testing. 

4.2  Interface  Board 

The  Interface  Board  is  used  to  provide  I2C,  digital  I/O,  and  analog  inputs  for  the 
C&DH  system  and  is  controlled  by  digital  outputs  and  a  USB  connection  from 
the  flight  computer.  It  also  is  used  to  turn  power  to  the  USB  hub  on  and  off. 
More  details  on  the  Interface  board  are  in  the  Command  and  Data  Handling 
Interface  Board  (DINO-CDH-RPT-INTBRD)  document. 

4.3  USB  Hub 

A  modified  off  the  shelf  USB  hub  will  be  used  to  provide  enough  USB  ports  for 
the  C&DH  system  if  the  Arcom  Viper  is  used  as  the  flight  computer.  This  is  a 
powered  hub  that  only  operates  when  it  is  turned  on,  and  power  to  this  hub  can 
be  switched  on  and  off  by  controls  sent  to  the  Interface  Board.  More  details  on 
the  hub  are  in  the  Command  and  Data  Handling  USB  Hub  (DINO-CDH-RPT- 
HUB)  document. 


5  Testing 

Initial  testing  running  software  on  the  flight  computers  with  connections  to  other 
subsystems,  the  Interface  Board,  and  the  USB  hub  has  been  successful.  Both  flight 
hardware  designs  using  the  Viper  and  Mercury  computers  will  be  built  and  tested  for 
hardware  integration  testing. 
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6  Appendix  A  -  List  of  Acronyms 

CPU  Central  Processing  Unit,  the  main  integrated  circuit  in  a  computer  system. 
C&DH  The  Command  and  Data  Handling  subsystem 
GPIO  General-purpose  input/output. 

I2C  Inter-Integrated  Circuit,  a  two-wire  bidirectional  synchronous  serial  protocol 
invented  by  Philips  Semiconductors.  I2C  is  used  by  many  small  and  inexpensive  D/A 
converters,  A/D  converters,  memories,  and  I/O  expansion  chips 

I/O  Input/Output 

RAM  Random  Access  Memory 

RS-232  A  full-duplex  asynchronous  serial  protocol  characteried  by  single  wires 
for  receive,  transmit,  and  each  flow  control  signal.  Signal  values  swing  between 
approximately  -15  and  4-5  Volts. 

RS-422  A  full-duplex  asynchronous  serial  protocol  using  one  twisted  pair  for 
transmit  and  one  twisted  pair  for  receive.  Signaling  is  via  5V  differential-drive. 

USB  Universal  Serial  Bus,  the  same  popular  serial  interface  used  by  modem  personal 
computers 
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1  Scope 

1 . 1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

This  document  covers  the  computers  used  in  the  Command  and  Data  Handling 
subsystem  that  will  run  the  flight  software  used  to  control  the  satellite. 

1 .5  Referenced  Documents 

No  other  documents  are  referenced. 


2  Description  of  Flight  Computer 

The  flight  computer  has  an  Intel  Xscale  CPU  running  a  Linux  kernel  and  the  flight 
software.  It  interfaces  with  other  hardware  in  the  Command  and  Data  Handling 
system  and  other  subsystems  using  RS-232,  RS-422,  USB,  and  digital  I/O  interfaces. 
There  are  2  computers  that  are  being  configured  and  tested  for  use  as  the  flight 
computer:  the  Viper  and  Mercury,  both  of  which  are  manufactured  by  Arcom. 

3  Arcom  Viper 

3 . 1  General  Description 

This  is  a  single  board  computer  with  a  PC/ 104  form  factor  based  around  an  Intel 
Xscale  CPU.  This  computer  was  the  first  choice  for  use  as  the  flight  computer 
before  the  Mercury  became  available. 
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Audio  -  IrvOutWlitfAmp 


Power 

<rnc  battery  input  &  reset) 


8/1 6-bit  PC/104  interface 


JTAG 


Intel  StrataFlash 


10/IOObaseTx  Ethernet 
Five  serial  ports  Ethernet  LEDs 


Intel  PXA255  XScale 
400MHz  processor 


J  Digital  yo  USB 
CompactFlash  - 


1TT/STN  Rat  Panel 


3.2  Hardware  Specifications 

.  400MH5Jntel  PXA255  XScale  CPU 

•  Redboot  firmware  with  Linux  support 

•  64  Megabytes  of  RAM 

•  1 6  Megabytes  of  Flash  memory 

•  CompactFlash  socket 

•  2  USB  ports 

•  100  megabit  Ethernet  interface 

•  4  RS-232  serial  ports 

•  1  RS-422/RS-485  serial  port 

•  8  GPIO  digital  inputs/  8  GPIO  digital  outputs 

Additional  information  on  this  computer  can  be  found  at  the  manufacturer's  web 
site  at  http://www.arcom.com/pc  1 04-xscale-viper.htm 
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4  Arcom  Mercury 


4.1 


General  Description 


This  is  a  new  PC/104  form  factor  Xscale  based  computer  that  was  recently 
introduced  by  Arcom,  and  is  very  similar  to  the  Viper  in  many  ways.  Is  has  a 
faster  CPU,  and  more  USB  ports.  It  will  be  used  as  the  flight  computer  if  all 
testing  using  it  is  successful. 

Intel  KP425  XScale  GF10  (8  inputs,  8  outputs)  ■ 

533MHz  processor  '  „ « 

x2  lOObaseTx  Ethernet 


.  i  nn  n  a 


j  Power 
'-Four  serial  ports 


64Mbyte  DRAM 
CompactFlash  (CF+) 
&16-bif  PC/104  interface 


4.2  Hardware  Specifications 

.  533MHzlntel  IXP425  XScale  CPU 

•  Redboot  firmware  with  Linux  support 

•  64  Megabytes  of  RAM 

•  1 6  Megabytes  of  flash  memory 

•  CompactFlash  socket 

•  4  USB  ports 

•  2  100  megabit  Ethernet  interfaces 

•  3  RS-232  serial  ports 

•  1  RS-422/RS-485  serial  port 

•  8  GPIO  digital  inputs/  8  GPIO  digital  outputs 
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Additional  information  on  this  computer  can  be  found  at  the  manufacturer's  web 
site  at  http://www.arcom.com/pcl04-ixp425-mercury.htm 

5  Testing 

Both  computers  have  run  test  versions  of  the  flight  software,  and  are  being  tested  for 
electrical  integration.  The  Viper  has  been  tested  more  than  the  Mercury  at  this  point, 
so  it  will  be  used  if  problems  with  the  Mercury  are  discovered.  If  both  computers  test 
successfully,  the  Mercury  will  be  used. 
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6  Appendix  A  -  List  of  Acronyms 

CPU  Central  Processing  Unit,  the  main  integrated  circuit  in  a  computer  system. 

GPIO  General-purpose  input/output. 

I/O  Input/Output 

RAM  Random  Access  Memory 

RS-232  A  full-duplex  asynchronous  serial  protocol  characteried  by  single  wires 
for  receive,  transmit,  and  each  flow  control  signal.  Signal  values  swing  between 
approximately  -15  and  15  Volts. 

RS-422  A  full-duplex  asynchronous  serial  protocol  using  one  twisted  pair  for 
transmit  and  one  twisted  pair  for  receive.  Signaling  is  via  5V  differential-drive. 

USB  Universal  Serial  Bus,  the  same  popular  serial  interface  used  by  modem  personal 
computers 
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1  Scope 

1 . 1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

This  document  describes  the  modification,  use  and  testing  of  the  USB  hub  used 
by  the  Command  and  Data  Handling  subsystem. 

1 .5  Referenced  Documents 

No  other  documents  are  referenced. 

2  USB  Hub  Description 

A  modified  commercial  off  the  shelf  USB  hub  is  used  with  the  Arcom  Viper 
flight  computer  because  this  computer  has  2  USB  ports,  and  the  total  number  of 
USB  devices  that  need  to  interface  with  the  computer  is  4. 

3  USB  Hub  Modification  Procedure 
3.1  Parts  and  Requirements 


Parts: 

Model  Number: 

1  Linksys  USB  2.0  4-Port  Hub 

USB2HUB4 

2  120p  Solid  Tantalum  Capacitors  SMD  -  min  10V  rating 

— 

5  4.7JI  Solid  Tantalum  Capacitors  SMD  -  min  10V  rating 

— 

4  120p  Solid  Tantalum  Capacitors  SMD  -  min  10V  rating 

— 

20  Header  Pins 

— 
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Requires: 

DC  5V,  2.4A  for  the  power  connector 
DC  5V,  500mA  max  for  the  USB  ports 

Tools  Needed: 

Fine  flathead  Screwdriver 
Needle  nose  Pliers 

Cutting  Tool  (small  in  sie,  but  can  cut  through  m  etal) 

Soldering  iron  with  conic  tip 

Solder 


3.2  Warnings 

1 .  Work  in  a  static-area  environment. 

2.  When  modifying  board,  be  extra  careful  as  the  other  components  of  the 
board  may  be  easily  knocked  off. 

3.3  Procedure 

1.  Acquire  the  USB  Hub  and  pry  off  the  sticker  that  reads  “ProConnect  ® 
USB  4-Port  Hub  USB  2.0.” 

2.  Remove  the  front  piece  of  black  plastic  that  covers  the  LEDs  with  the 
words:  POWER4  3  2  1.” 

3.  Use  the  fine  flathead  screwdriver  and  wedge  it  into  the  slit  on  the  side  of 
the  cover.  It  is  recommended  to  place  the  screwdriver  closer  to  the  front  of 
the  hub  as  the  bracket  is  there. 

4.  Apply  enough  upward  force  until  the  side  breaks  open.  Do  the  same  to  the 
other  side. 

5.  Remove  the  hub  from  its  housing. 

6.  Use  the  pliers  and  grab  onto  the  housing  of  the  green  LEDs.  Apply  a 
rocking  left  and  right  motion  until  the  LEDs  and  its  housing  are  detached. 

7.  When  looking  at  the  left  half  of  the  USB  connector,  it  has  a  “C”  shaped 
metal  housing.  Take  the  pliers  and  grab  onto  the  bottom  portion  of  the  “C” 
and  bend  it  to  create  a  “S.”  Do  the  same  for  the  other  half. 

8.  Lift  the  metal  upward  so  that  it  is  perpendicular  to  the  board  and  using  the 
pliers  on  the  metal,  apply  a  rocking  motion  on  it  until  the  metal  snaps  off 
the  board. 

9.  Repeat  steps  7  and  8  for  the  rest  of  the  USB  connectors. 

10.  After  the  metal  housing  has  been  removed,  use  the  pliers  and  grab  onto  the 
plastic  portion  of  the  USB  connector.  Raise  this  plastic  upwards  until  it  is 
perpendicular  to  the  board  and  use  the  cutting  tool  and  cut  into  the  plastic 
until  it  is  removed.  Repeat  for  the  other  3  connectors. 

11.  Use  the  cutting  tool  and  remove  the  Type-B  USB  connector. 

12.  Use  the  cutting  tool  and  remove  the  power  housing. 

13.  To  remove  the  capacitors:  use  the  pliers  and  grab  onto  the  casing  on  the 
electrolytic  capacitor  and  keep  twisting  it  while  forcing  it  up  until  it  comes 
off. 
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14.  Using  a  soldering  iron,  remove  the  extra  metal  in  the  PCB  for  the  4  USB 
pins.  Do  this  for  the  5  USB  ports. 

15.  Replace  with  4  headers  each  and  solder  them  in  with  the  long  end  facing 
up. 

16.  On  the  bottom  of  the  board,  solder  the  tantalum  capacitors  to  the  extra  wire 
sticking  out  of  the  PCB. 

C18,C19-  lOOp 

C14,  C37,  C23,  C31,  C20  -  4.7p 

Cl  1,  05,  C9,  C7-120p 

17.  Clip  off  any  excess  pins  and  wires  if  exists. 


3.4 
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4  Testing  the  Modified  USB  Hub 

The  modified  hub  has  been  tested  with  various  USB  devices  (such  as  the  cameras 
from  the  Science  system)  usifig  connections  where  power  is  drawn  from  the  hub, 
and  also  when  power  is  provided  to  USB  devices  from  a  separate  source,  and  will 
work  either  way.  This  hub  is  not  self  powered  and  will  only  work  when  5  volts  is 
supplied  to  the  power  connector. 
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USB  Universal  Serial  Bus,  the  same  popular  serial  interface  used  by  modem  personal 
computers 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

This  document  describes  the  Interface  Board,  which  is  connected  to  the  flight 
computer  to  provide  additional  analog  and  digital  inputs  and  outputs  used  to 
interface  with  other  subsystems. 

1 .5  Referenced  Documents 

The  Report  on  Microcontrollers  (DINO-SW-RPT-MICROS)  is  referenced  in 
this  document. 
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2  Reasons  for  Interface  Board  Design 

2.1  The  Need  for  Additional  Interfaces 

The  flight  computer  has  multiple  serial  ports,  USB  ports  and  digital  GPIO  lines, 
but  all  of  this  is  not  enough  to  interface  with  all  other  subsystems  on  the 
satellite  without  adding  additional  hardware.  An  early  version  of  the  interface 
requirements  list  demonstrates  this: 


System 

Digital  Out 

Digital  In 

Analog  Out 

Analog  In 

ADCS 

3 

0 

3 

9 

Comm 

0 

0 

0 

0 

Power 

1 

0 

0 

0 

Mech 

0 

2 

0 

11  or  17 

Science 

1 

1 

0 

0  +  2x  USB 

Thermal 

0 

0 

0 

30 

Tip  Mass 

0 

0 

0 

0 

TOTALS 

4 

3 

3 

50  or  56 

2.2 

Off  the  Shelf  Hardware  vs.  Custom  Designed  Hardware 

Earlier  revisions  of  the  C&DH  subsystem  design  involved  use  of  a  commercial 
off  the  shelf  interface  board  connected  to  the  fight  computer  using  the  PC/104 
bus.  This  approach  had  to  be  abandoned  when  it  was  determined  that  a  custom 
design  would  be  simpler  to  implement  for  multiple  reasons. 

The  primary  reason  use  of  an  off  the  shelf  interface  board  was  abandoned  is  the 
limited  support  for  these  commercial  boards  for  the  CPU  and  Operating  System 
used  on  the  flight  computer.  The  flight  computer  uses  an  Intel  Xscale  CPU  and 
runs  the  Linux  Operating  System.  Some  vendors  only  released  binary  Linux 
drivers  for  their  boards  and  did  not  make  source  code  available,  with  no  support 
for  the  Xscale  CPU.  Even  with  source  code  available,  attempts  to  port  x86  based 
drivers  to  work  with  the  Xscale  based  flight  computer  were  not  initially 
successful.  It  became  apparent  that  it  would  be  simpler  to  implement  a  custom 
hardware  solution  than  to  writing  or  porting  a  driver  for  a  commercial  board. 

The  interface  board  is  based  on  the  RCPOD  design,  which  had  been  used 
successfully  in  previous  projects  by  members  of  the  Software  team.  This  design 
uses  a  Microchip  PIC16C765  microcontroller  which  interfaces  to  the  flight 
computer  using  USB  and  provides  several  analog  and  digital  inputs  and  outputs. 
The  RCPOD  firmware  also  allows  the  digital  I/O  to  be  configured  to  be  used  as 
I2C  bus  connections  through  its  driver  software.  Use  of  the  I2C  bus  drastically 
reduces  the  total  number  of  wires  needed  to  interface  with  other  systems  when 
compared  with  earlier  designs  that  used  discrete  analog  and  digital  lines.  More 
details  on  the  RCPOD  hardware  and  software  features  are  in  the  Report  on 
Microcontrollers  (DINO-SW-RPT-MICROS)  document. 
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3  Hardware  on  the  Interface  Board 

The  PIC16C765  microcontroller  is  not  the  only  integrated  circuit  on  this  board.  There 

is  also  a  thermal  sensor,  a  digital  line  driver,  2  power  regulators,  and  a  power  switch. 

3.1  PIC  Microcontroller 

The  PIC16C765  microcontroller  using  RCPOD  firmware  is  controlled  and 
powered  by  its  USB  connection  to  the  flight  computer.  It  provides  digital  GPIO 
and  I2C  interfaces,  as  well  as  8  bit  analog  inputs.  The  reset  line  for  the 
microcontroller  is  connected  to  digital  output  5  from  the  flight  computer  and 
must  be  driven  high  to  enable  the  microcontroller.  This  line  is  connected  to  a 
pulldown  resistor  going  to  ground  so  the  microcontroller  will  be  held  in  a  reset 
state  if  the  digital  output  from  the  flight  computer  is  not  enabled  and  being 
driven  high. 

3.2  Digital  Line  Driver 

A  74HCT244  line  driver  is  used  to  expand  the  I2C  clock  output  from  pin  RB6 
(labeled  SCL  in  the  schematic)  on  the  PIC16C765  to  be  used  as  the  clock  for  all 
I2C  buses.  Using  a  line  driver  keeps  more  digital  I/O  pins  on  the  PIC  available, 
while  preventing  a  short  on  one  of  the  I2C  clock  lines  from  disabling  all  I2C 
buses.  To  enable  the  outputs  for  the  line  driver,  pin  RB7  on  the  PIC16C765 
(labeled  SCLEN  in  th  e  schematic)  must  be  driven  low.  A  pullup  resistor  is 
connected  to  the  output  enable  lines,  so  output  is  disabled  by  default  if  the 
output  from  the  PIC  is  not  enabled  and  driven  low. 

3.3  Thermal  Sensor 

A  surface  mount  Microchip  TC74  I2C  thermal  sensor  is  soldered  to  the 
Interface  Board  and  provides  temperature  readings  for  the  C&DH  subsystem.  It 
is  connected  to  I2C  Thermal  Bus  4. 

3.4  Power  Regulators 

A  pair  of  Maxim  8867  power  regulators  are  used  to  switch  power  to  the  analog 
and  I2C  thermal  sensors  on  and  off.  They  also  limit  the  amount  of  current  that 
would  be  drawn  from  the  I/O  board  if  there  is  a  short  circuit  on  these  power 
buses.  The  enable  inputs  for  these  power  regulators  are  connected  to  pulldown 
resistors  so  that  the  power  outputs  are  disabled  unless  the  digital  outputs  from 
the  flight  computer  are  enabled  and  driven  high.  The  power  to  the  analog 
thermal  sensors  is  controlled  by  digital  output  7  from  the  flight  computer,  and 
the  power  to  the  I2C  thermal  sensors  is  controlled  by  digital  output  6  from  the 
flight  computer. 
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3.5  Power  Switch 

An  IRF7410  MOSFET  and  a  2N3904  BT  act  as  a  high  current  power  switch 
that  can  be  used  to  switch  power  to  a  device  connected  to  the  C&DH  power  bus 
on  and  off.  This  switch  circuit  is  connected  to  digital  output  4  of  the  flight 
computer,  and  must  be  driven  high  to  turn  power  on. 
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BJT  Bipolar  inction  Transistor,  a  popular  category  of  transistors  that  act  as 

current  amplifiers 

C&DH  The  Command  and  Data  Handling  subsystem 

CPU  Central  Processing  Unit,  the  main  integrated  circuit  in  a  computer  system. 

GPIO  General-purpose  input/output. 

I2C  Inter-Integrated  Circuit,  a  two-wire  bidirectional  synchronous  serial 

protocol  invented  by  Philips  Semiconductors.  I2C  is  used  by  many  small 
and  inexpensive  D/A  converters,  A/D  converters,  memories,  and  I/O 
expansion  chips 

I/O  Input/Output 

MOSFET  Metal  Oxide  Semiconductor  Field  Effect  Transistor,  a  transistor 

technology  that  performs  much  better  at  power  switching  applications  than 
typical  BTs. 

USB  Universal  Serial  Bus,  the  same  popular  serial  interface  used  by  modem 

personal  computers 
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Appendix  B  -  Schematic  of  Interface  Board 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

This  document  covers  the  reason  for  choosing  the  BP-96A  packet  modem  for 
DINO’s  communication  system,  and  how  we  integrated  it  to  the  radios  and 
flight  computer. 

1 .5  Referenced  Documents 

BayPac  of  Tigertronics  (1997).  BayPac  BP-96  A  Packet  Modem  12-03-04 
http://www.tigertronics.com/filcs/bp96aman.pdf 

Micro  Controller  Documentation  (2004).  DINO-SW-RPT-MICROS 

2  TNC  Specification 

The  TNC  specifications  : 

Compatibility:  G3RUH  9600  baud  DFM 

PAR9600  /  PICPAR  /  BP-96 

Computer  Interface:  Centronics  Parallel  Port 

Power:  Computer  Parallel  Port  (5ma)  or  external  power 

source  of  8-  to  14  volts  @0m  a 

Signals:  PTT  (active  low)  75ma  ($2v  (MAX). 

Rx  Input  300mv  p-p  (nom) 

Tx  Output  0  -  3v  p-p 
Connectors:  Parallel  Port  -  DB-25M 
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Radio  Port  -  DB-9F 

Power  -  5.5  x  2.1  mm  (Center  )- 

Sie:  7/8”  H  x  2-1/4”  W  x  3”  D 

Case:  Molded  ABS  -  Gray/White 

Construction:  Surface  Mount  Technology  (SMT) 

3  TNC  Modifications 

TNC  modifications: 

Replace  the  only  electrolytic  capacitor  on  the  TNC  with  a  tantalum  capacitor 
(&2JQ. 


4  TNC  Interface 

See  the  Micro  Controller  Documentation  (DINO-SW-RPT-MICROS). 

5  TNC  Testing 

The  TNC’s  have  tested  to  be  fully  functional  with  the  microcontroller  board.  For 
information  about  testing  the  TNC/Microcontroller  board  unit,  refer  to  the  Micro 
Controller  Documentation  (DINO-SW-RPT-MICROS). 
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TNC  -  Terminal  Node  Controller 
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1  Scope 

1 . 1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1.4  Document  Overview 

This  document  pertains  to  the  boom  braking  box  which  is  intended  to  be  a 
slowdown  mechanism  for  the  deployed  Tip  Mass.  The  boom  braking  box  is 
partially  housed  within  the  Tip  Mass,  and  pieces  of  tape  measure  material  are 
wound  inside  the  box  -  specifically,  clamped  between  two  mated  spindles.  The 
boom  braking  box  is  supposed  to  be  set  in  motion  by  the  activation  of  the 
Lightband.  Sheer  momentum  keeps  the  Tip  Mass  moving  and  the  interaction 
between  gears  housed  within  the  box  give  it  the  ability  to  slowly  wind  down 
which  should  adequately  decelerate  the  whole  structure. 

1 .5  Referenced  Documents 

The  following  is  a  list  of  all  documents  related  to  the  boom  braking  box  design 
and  construction.  Please  note:  the  nomenclature  is  of  the  form  MissionName- 
MissionSubsystem(Mechanisms)-DocumentType(Drawing)-ComponentName. 

DINO-MECH-DWG-CNTPAN 

DINO-MECH-DWG-BXSIDE 

DINO-MECH-DWG-INSPIN 

DINO-MECH-DWG-OUTSPIN 

DINO-MECH-DWG-LGGEAR 

DINO-MECH-DWG-GSPOOL 

DINO-MECH-DWG-DRSHFT 
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DINO-MECH-DWG-SHFTMT 

DINO-MECH-DWG-RATCHET 

DINO-MECH-DWG-SPRROD 

DINO-MECH-DWG-RPAWL 

DINO-MECH-DWG-LPAWL 

DINO-MECH-DWG-PINGUI 

DINO-MECH-DWG-RODGUI 

DINO-MECH-DWG-ADBK 

DINO-MECH-DWG-SCRSPR 

DINO-MECH-DWG-OUTPAN 

DINO-MECH-DWG-TGUIDEL 

DINO-MECH-DWG-TGUIDER 

DINO-MECH-DWG-SPACER 

DINO-MECH-DWG-CENTGUI 

DINO-MECH-DWG-INNGUI 

DINO-MECH-DWG-OUTGUI 

DINO-MECH-DWG-ROLLER 

DINO-MECH-ASM-BBBOX 

DINO-MECH-ASM-GSETR 

DINO-MECH-ASM-GSETL 

2  Boom  Components 

The  following  is  a  list  of  all  parts  encompassing  the  boom  braking  box  assembly  and 
mounting  components 

DINO-MECH-DWG-CNTPAN :  Central  panel 
DINO-MECH-DWG-BXSIDE:  Open  box  side  panel  (2) 
DINO-MECH-DWG-INSPIN:  Inner  spindle  (2) 

DINO-MECH-DWG-OUTSPIN :  Outer  spindle  (2) 

DIN O-MECH-D W G-LGGE AR :  Large  gear  (2) 

DINO-MECH-DWG-GSPOOL:  Gear  mount  spool  (4) 
DINO-MECH-DWG-DRSHFT :  Drive  shaft  (2) 

DINO-MECH-DWG-SHFTMT:  Shaft  mount  (2) 

DINO-MECH-DWG-RATCHET:  Ratchet  gear  (2) 

DINO-MECH-DWG-SPRROD:  Spring  rod  (2) 

DINO-MECH-DWG-RPAWL:  “Right”  pawl 
DINO-MECH-DWG-LPAWL:  “Left”  pawl 
DINO-MECH-DWG-PINGUI:  Right  side  rod  guide  for  right  pawl 
DINO-MECH-DWG-RODGUI:  Left  side  rod  guide  for  left  pawl 
DINO-MECH-DWG-ADBK:  Sp  ring  adjustment  bracket 
DINO-MECH-DWG-SCRSPR:  Screw  for  spring  adjustment 
DINO-MECH-DWG-OUTPAN:  Outer  panel  for  Boom  breaking  box 
DINO-MECH-DWG-TGUIDEL:  Left  tape  measure  guide 
DINO-MECH-DWG-TGUIDER:  Right  tape  measure  guide 
DINO-MECH-DWG-SPACER:  Outer  panel  spacer 
DINO-MECH-DWG-CENTGUI:  Center  tape  measure  guide 
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DINO-MECH-DWG-INNGUI:  Inner  tape  measure  guide  (center) 
DINO-MECH-DWG-OUTGUI:  Outer  tape  measure  guide  (center) 
DINO-MECH-DWG-ROLLER:  Tape  measure  roller  (4) 

3  Boom  Assembly  and  Mounting  Procedures 
3 . 1  Gear  Sub-assembly 

The  mounting  of  the  gears  to  each  other  requires  that  the  inner  spindle  and  the 
outer  spindle  be  mated  to  each  other  via  two  #4-40  1/2”  socket  head  screws. 
The  screws  fit  into  the  outer  spindle  and  down  into  the  inner.  On  both  sides  of 
this  assembly  go  two  spools.  The  spools  fit  over  the  spindle  assembly,  the 
spindles  fitting  into  0.05”  pockets  in  the  sides  of  the  gear  spools.  The  large  gear 
on  the  backside  of  the  screw  mates  to  the  spools  and  spindles  both  by  way  of 
three  #4-40  3/16”  counter-sunk  screws.  Through  all  of  the  parts  fits  a  1/4”  rod  2 
%long;  there  is  a  notch  on  the  rod  that  fits  the  shaft  mount.  To  the  shaft  mount 
fits  a  ratchet  gear  connected  with  three  #4-40  3/16”  counter-sunk  screws.  The 
drive  shaft  fits  through  the  hole  in  the  central  panel  and  the  outer  panel  on  the 
backside.  There  are  two  drive  shafts  as  there  are  two  gear  assemblies.  The  gear 
assemblies  should  be  mounted  so  that  the  teeth  of  the  ratchet  gears  appear  to 
move  away  from  the  interior  of  the  box.  The  spindles  have  exactly  the  opposite 
formation  -  that  is,  towards  the  center  guide. 


3.2  Box  assembly 

The  central  panel  of  the  boom  braking  box  fits  two  measure  guides  to  it  by  four 
#4-40  7/16”  screws.  Also,  the  central  panel  in  front  mounts  the  tape  measure 
guide  that  runs  up  through  the  main  body  of  the  box.  First,  to  the  central  panel 
is  mated  an  elliptical  spacer  via  two  #4-40  3/4”.  The  screws  also  run  through 
the  outer  guide  and  into  the  center  tape  measure  guide.  On  the  backside  of  this 
central  guide  piece  is  another  guide  cover  that  fits  to  the  center  guide  with  at 
single  #4-40  1/4”  socket  head  screw.  Between  the  inner  and  outer  guides,  four 
rollers  are  fitted  concentrically  to  the  four  pertinent  holes  in  the  guides  pieces, 
and  they  can  be  secured  by  two  4/2  ”  dowels  held  in  place  by  lock  washers  and 
nuts.  To  the  central  panel  fits  two  side  box  panels;  view  the  document  DINO- 
MECH-ASM-BBBOX  to  verify  the  proper  orientation  of  the  boxes.  Each  side 
panel  fits  to  the  central  panel  by  three  #4-40  3/16”  socket  head  screws.  Once 
the  shafts  are  put  into  place,  the  outer  panel  can  be  attached.  It  also  mates  to  the 
side  box  panels  by  three  #4-40  3/16”  screws  on  either  side.  To  the  1/8”  holes  in 
the  side  of  the  outer  panel,  two  rods  run  through  to  give  mount  to  the  two  pawls. 
The  pawls  should  be  situated  0.1”  from  the  inside  wall  of  the  outer  panel. 
Above  each  are  the  rod  guides  -  one  being  designated  a  “pin  guide”  -  to  hold 
the  spring  rod.  The  spring  rod  continually  pushes  down  on  each  pawl  which 
themselves  push  down  on  the  ratchet.  The  geometry  of  the  ratchet  ensures  that 
the  movement  of  that  gear  and  the  drive  shaft  that  it  is  attached  to  are  impeded. 
There  is  an  adjustment  bracket  above  the  larger  of  the  two  pawls.  Its  purpose  is 
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to  provide  resistance  as  necessary  to  increase  the  ratcheting  power  of  the 
deployment. 


3.3  Mounting  Procedures 

There  are  holes  in  the  base  of  the  side  panels,  and  those  holes  fit  under  the  Tip 
Mass  box  structure.  With  two  #8-32  screws,  the  boom  braking  box  can  be  held 
in  place.  The  center  guide  piece  must  be  facing  downwards  on  the  satellite, 
towards  the  nadir  plate. 
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Appendix  A  -  List  of  Acronyms 

DINO  -  Deployable  and  Intelligent  Nanosatellite  Operations,  referring  to  the  Colorado 
Space  Grant  mission  entry  for  Nanosat  III. 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1.4  Document  Overview 

This  document  pertains  to  the  deployment  of  the  CTD  experiment  panel 
onboard  the  DINO  satellite.  The  panel  is  connected  to  and  deployed  by  shape- 
memory  composite  hinges  courtesy  of  Composite  Technology  Development, 
Inc.  The  CTD  experiment  panel  is  one  of  the  various  deployable  mechanisms 
for  the  DINO  mission.  In  order  that  CTD,  Inc.  may  have  quantitative  data 
determining  the  performance  of  its  composite  hinges,  the  CTD  experiment  panel 
will  mount  a  rate  gyro  sensor  board  to  test  relative  acceleration.  The  CTD 
experiment  panel  will  be  successfully  deployed  so  long  as  the  appropriate 
Wattage  is  supplied  to  the  composite  hinges,  and  so  long  as  the  FrangiBolt 
restraint  is  successfully  released.  The  FrangiBolt  is  a  device  supplied  to 
Colorado  Space  Grant  Consortium  by  the  TiNi  Aerospace  company.  Inside  this 
device  is  a  composite  material  that,  when  heated,  expands  in  such  a  way  so  as  to 
stress  the  release  bolt  and  break  it  in  two.  This  document  will  elaborate  on  the 
processes  that  will  ensure  a  successful  deployment  of  the  CTD  experiment 
panel. 

1 .5  Referenced  Documents 

The  following  is  a  list  of  all  documents  related  to  the  CTD  experiment  panel 
design  and  construction.  Please  note:  the  nomenclature  is  of  the  form 
MissionName-MissionSubsystem(Mechanisms)-DocumentType(Drawing)- 
ComponentName. 


Page  4  of  10 


85  of  190 


DINO:  CTD  Experiment 


DINO-MECH-RPT-CTD,  Rev.  A 


DINO-MECH-DWG-EXPPAN 

DINO-MECH-DWG-CPCONE 

DINO-MECH-DWG-PANMNT 

DINO-MECH-DWG-RELEASE 

DINO-MECH-DWG-SBOARD 

DINO-MECH-DWG-CTDHNG 

DINO-MECH-DWG-ISOMNT 

DINO-MECH-ASM-PANEL 

DINO-MECH-ASM-CTDPAN1 

DINO-MECH-ASM-CTDPAN2 

DINO-MECH-DWG-FRACT 

DINO-MECH-DWG-FHOUSE 

DINO-MECH-DWG-CPLATE 

DINO-MECH-DWG-CSLIDE 

DINO-MECH-DWG-OUTSPR 

DINO-MECH-DWG-INNSPR 

DINO-MECH-DWG-FRBOLT 

DINO-MECH-DWG-SPRWASH 

DINO-MECH-DWG-FRMNT 

DINO-MECH-ASM-WASHERS 

DINO-MECH-ASM-FSLIDE 

DINO-MECH-ASM-FRANGI 


2  CTD  Components 

The  following  is  a  list  of  all  parts  encompassing  the  CTD  experiment  panel  assembly 
and  mounting  components 


DINO-MECH-DWG-EXPPAN  -  Experiment  panel  (1) 
DINO-MECH-DWG-CPCONE  -  Cup  cones  (3) 
DINO-MECH-DWG-PANMNT  -  Panel-side  hinge  mounts  (2) 
DINO-MECH-DWG-RELEASE  -  Panel  release  eye  (1) 
DINO-MECH-DWG-SBOARD  -  Panel  mounted  sensor  board  (1) 
DINO-MECH-DWG-CTDHNG  -  Shape-memory  composite  hinges  (2) 
DINO-MECH-DWG-ISOMNT  -  Isogrid-side  hinge  mounts  (2) 
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3  CTD  Assembly  and  Mounting  Procedures 
3 . 1  Panel  Sub-assembly 

To  begin  the  assembly  of  the  deployable  CTD  panel,  start  with  the  experiment 
panel  itself  designated  “EXPPAN.”  There  is  a  link  to  that  part  above,  saved  as  a 
drawing  file,  as  well  as  a  link  to  all  other  parts  listed  in  this  document.  The 
nomenclature  is  consistent  throughout.  Various  parts  are  attached  to  the  panel 
and  they  are: 

PANMNT  -  Two  hinge  mounts  for  the  CTD  shape-memory  composite  hinges. 
Each  mount  is  mated  to  the  panel  by  two  #8-32  3/4"  socket  head  screws. 
CPCONE  -  Three  half  cylindrical  “cones”  mate  to  the  pocketed  side  of  the 
experiment  panel  by  two  #4-40  5/8”  socket  head  screws. 

SBOARD  -  The  rate  gyro  sensor  board  fits  onto  the  experiment  panel  by  three 
#6-32  3/4”  socket  head  screws.  The  sensor  board  is  at  the  bottom  of  one  of  the 
material  pockets  on  the  experiment  panel.  It  is  mounted  on  stand-offs,  however, 
being  1/4”  tall  each. 

RELEASE  -  The  release  eye  is  a  component  that  is  also  attached  to  the 
FrangiBolt  assembly  which  is  the  release  mechanism  for  the  panel  deployment. 
The  release  eye  is  mated  to  the  experiment  panel  by  two  #2-56  3/16”  socket 
head  screws. 


3.2  Mounting  Procedures 

To  mount  the  CTD  experiment  panel  assembly  to  the  DINO  satellite,  the 
isogrid-side  hinge  mounts  need  to  be  mated  to  the  main  structure.  Those  hinge 
mounts  are  designated  “ISOMNT”  and  are  attached  to  the  satellite  by  three  # JO- 
32  1/2”  socket  head  screws.  The  mounts  in  turn  fit  two  #6-32  1/2”  socket  head 
screws.  The  screws  in  question  go  through  the  CTD  hinge  anchors  to  mate  with 
the  panel-side  hinge  mounts  and  the  isogrid-side  hinge  mounts  both  in  the  same 
way.  Once  the  panel  is  attached  to  the  main  structure  via  the  composite  hinges, 
it  can  be  locked  into  place  with  the  release  eye  component  and  the  FrangiBolt. 
In  order  to  prepare  the  panel  for  stowing,  the  hinges  must  first  be  supplied  with 
the  appropriate  electrical  power.  With  the  supply  of  0.6  V  at  1  A,  the  composite 
hinges  should  become  pliable  enough  to  bend  into  formation.  A  1”  round  dowel 
(over  which  the  hinges  bend)  should  be  used  to  get  the  specified  curvature  for 
the  hinges.  Once  the  release  eye  is  in  its  position  relative  to  the  isogrid,  the 
FrangiBolt  can  be  put  in  place  through  the  opening  of  the  release  eye.  Each  cup 
cone  should  fit  snugly  into  the  grooves  located  alongside  the  isogrid  panel.  A 
view  of  the  isogrid  in  question  can  be  found  in  the  “CTDPAN”  assemblies,  but 
also  in  documentation  from  the  Structures  subsystem  team.  The  experiment 
panel  can  be  locked  into  place  with  clamps  and  Belleville  washers,  the  latter 
being  for  accurate  tightening.  The  pre-tensioned  force  in  place  can  be 
determined  from  the  compression  displacement  of  the  washers. 
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4  CTD  Deployment  and  Performance 

4 . 1  Experiment  Panel  Deployment 

Successful  deployment  of  the  experiment  panel  will  occur  if  the  proper  power 
supply  is  provided  to  the  composite  hinges,  and  if  the  FrangiBolt  successfully 
releases.  If  0.6  V  at  1  A  is  supplied  to  the  hinges  as  is  planned,  the  hinges 
should  be  fully  prepared  to  unfold.  When  the  hinges  reach  their  temperature 
limit,  power  supply  is  supposed  to  shut  off.  At  around  the  same  time,  the 
FrangiBolt  is  supposed  to  be  actuated.  This  actuation  causes  the  FrangiBolt  bolt 
to  break  in  two  thus  freeing  the  CTD  panel  from  restraint. 

4.2  Performance  Metrology 

The  kinematics  of  the  panel  deployment  can  be  measured  from  the  rate  gyro 
sensors  mounted  onboard  the  experiment  panel  itself.  The  specifics  of  this 
measurement  should  be  detailed  in  the  appropriate  documentation. 

5  FrangiBolt  Components 

The  following  is  a  list  of  all  parts  encompassing  the  FrangiBolt  assembly  and 
mounting  components 

DINO-MECH-DWG-FRACT  -  FrangiBolt  actuator  (1) 
DINO-MECH-DWG-FHOUSE  -  FrangiBolt  actuator  housing  (1) 
DINO-MECH-DWG-CPLATE  -  Slide  cover  plate  (1) 
DINO-MECH-DWG-CSLIDE  -  Sliding  component  inside  cover  plate  (1) 
DINO-MECH-DWG-OUTSPR  -  Outer  spring  with  greater  diameter  (1) 
DINO-MECH-DWG-INNSPR  -  Inner  spring  with  smaller  diameter  (1) 
DINO-MECH-D WG-FRBOLT  -  FrangiBolt  bolt  #8(1) 
DINO-MECH-DWG-SPRWASH  -  Spring  washers  (10) 
DINO-MECH-DWG-FRMNT  -  FrangiBolt  mount  (1) 


6  FrangiBolt  Assembly  and  Mounting  Procedures 

6.1  FrangiBolt  Assembly 

The  FrangiBolt  assembly  has  a  few  components  associated  with  it.  Firstly,  the 
outer  housing  consists  of  the  FrangiBolt  housing  (FHOUSE)  and  the  cover  slide 
plate  (CPLATE).  The  assembly  procedures  for  these  two  parts  will  be 
elaborated  below,  but  first,  here  are  the  individual  component  parts: 

CSLIDE  -  This  part  fits  within  the  cover  slide  plate.  The  face  is  oriented  in  the 
same  way  as  the  pocketed  face  of  the  cover  slide  plate.  Its  position  within  the 
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cover  slide  plate  is  determinate  upon  the  final  tightness  of  the  two  portions  of 
the  outer  FrangiBolt  housing. 

OUTSPR  -  This  spring  fits  around  the  inner  spring  and  it  also  fits  behind  the 
cover  slide.  The  cover  slide  is  supposed  to  back  up  into  the  pocket  of  the  cover 
slide  plate  with  both  springs  behind  it.  As  the  cover  slide  plate  and  the 
FrangiBolt  housing  are  screwed  together,  the  cover  slide  should  move  slightly 
backwards  into  the  pocket  of  the  cover  slide  plate.  This  is  because  the 
FrangiBolt  bolt  will  be  pressed  up  against  it  on  one  side,  and  the  springs  on  the 
other  side. 

INNSPR  -  The  inner  spring  will  fit  inside  the  outer  spring,  and,  in  the  same 
way,  it  will  buttress  the  cover  slide. 

FRACT  -  The  FrangiBolt  actuator  sits  upright  in  the  pocket  on  the  side  of  the 
FrangiBolt  housing.  It’s  held  in  place  by  the  bolt  that  runs  through  it  and  on 
through  to  the  pocketed  face  of  the  FrangiBolt  housing.  The  bolt  has  washers 
stacked  below  the  bolt  head  which  keep  it  in  place  until  the  point  of  breaking. 
SPRWASH  -  There  are  10  washers  behind  the  bolt  head  that  prevent  the  bolt 
from  moving  prior  to  actuation,  and  also  keep  the  bolt  from  reentering  the  hole 
that  would  prevent  the  release  of  the  CTD  experiment  panel.  The  washers  fit 
around  the  bolt  and  are  paired  so  that  every  two  have  their  concave  faces 
towards  each  other. 

FRBOLT  -  The  FrangiBolt  bolt  goes  through  the  length  of  the  FrangiBolt 
housing.  The  ten  washers  buttress  it  on  the  backside  of  the  dually  pocketed  face 
of  the  housing.  Further,  the  bolt  runs  through  the  actuator. 

FRMNT  -  The  FrangiBolt  mount  mates  to  the  CTD  isogrid  panel  and  it  fits  the 
whole  FrangiBolt  housing  in  the  raised  pocket  of  the  material. 


6.2  Mounting  Procedures 

To  begin,  the  FrangiBolt  mount  can  first  be  attached  to  the  isogrid  structure,  on 
the  CTD  isogrid  panel  and  towards  the  interior  of  the  structure.  The  elevated 
pocket  on  top  of  the  FrangiBolt  mount  should  face  towards  the  center  of  the 
DINO  structure.  For  the  full  mounting  geometry,  review  documents  DINO- 
MECH-ASM-CTDPAN 1  and  DINO-MECH-ASM-CTDPAN2.  The  FrangiBolt 
mount  is  attached  to  the  isogrid  panel  by  four  #10-32  1/2”  socket  head  screws 
and  lock  washers  for  each.  The  FrangiBolt  bolt  can  first  be  fitted  into  the 
FrangiBolt  housing,  FHOUSE.  Behind  the  head  should  be  the  10  spring 
washers  that  can  be  seen  in  their  proper  formation  in  the  document  DINO- 
MECH-ASM-WASHERS.  These  washers  further  fit  into  the  pocketed  face  at 
the  end  of  the  FrangiBolt  housing.  The  bolt  should  be  slid  through  the  hole  in 
the  FrangiBolt  housing,  and  should  be  passed  through  the  release  eye  DINO- 
MECH-DWG-RELEASE  which  extends  into  the  depth  cut  in  the  FrangiBolt 
housing.  The  release  eye  can  be  mated  to  the  CTD  experiment  panel  from  that 
point.  Aside  from  fitting  through  the  release  eye,  the  bolt  should  fit  through  the 
FrangiBolt  actuator.  The  actuator  fits  in  a  pocketed  side  of  the  FrangiBolt 
housing  with  all  wiring  being  oriented  towards  the  opening  cut  in  the  bottom  of 
the  FrangiBolt  mount.  Now,  the  components  of  the  sliding  device  should  be 
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fitted  into  the  pocket  of  the  cover  slide.  The  smaller  diameter  spring  fits 
through  the  larger  diameter  spring,  and  both  go  behind  the  slide  cover.  The 
cover  slide  and  the  springs  should  be  compressed  into  the  pocketed  face  of  the 
cover  plate  with  the  cover  slide  facing  outward.  The  cover  plate  and  the 
FrangiBolt  housing  (bolt  included)  must  be  pressed  together  and  mated  with  4 
#6-32  1  V”  socket  head  screws.  This  is  the  FrangiBolt  housing  in  total.  It  is,  in 
turn,  mounted  to  the  FrangiBolt  mount  by  four  #4-40  3/8”  socket  head  screws. 
The  document  DINO-MECH-ASM-FRANGI  displays  the  proper  orientation  of 
the  assembly  itself. 


7  FrangiBolt  Deployment 

7.1  Deployment 

The  FrangiBolt  actuator  requires  only  the  proper  power  supply  to  operate 
successfully.  The  actuator  uses  25  W  at  28  V  and  should  be  controlled  by  input 
from  the  thermal  sensors  attached.  Once  the  device  reaches  its  expected 
temperature  power  is  cut  off. 
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Appendix  A  -  List  of  Acronyms 

DINO  -  Deployable  and  Intelligent  Nanosatellite  Operations,  referring  to  the  Colorado 
Space  Grant  mission  entry  for  Nanosat  III. 

CTD  -  Composite  Technology  Development,  Inc.;  the  company  supplying  the  unique 
shape-memory  composite  hinges  for  the  DINO  program. 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1.4  Document  Overview 

This  document  details  the  mission  operations  plan  for  the  DINO  mission.  The 
phases  of  the  mission  and  the  tools  used  to  plan  for  the  mission  are  outlined. 

1 .5  Referenced  Documents 

Space  Mission  Analysis  and  Design  3rd  Edition  by  Wertz  and  Larson 

DINO-ADCS-RPT-ADCS 

DINO-SW-RPT-SW 

2  Introduction 

The  DINO  Mission  Operations  Plan  (MOP)  describes  the  operational  characteristics 
of  the  flight  and  ground-based  elements  of  the  DINO  command  and  data  systems  and 
the  roles  of  operations  personnel. 

3  Mission  Concept 

DINO  is  a  student-designed  and  -built  low-earth  orbit  satellite  with  the  mission  of 
measuring  cloud  topography  from  space,  performing  on-board  data  analysis,  and 
evaluating  three  deployment  technologies.  The  first  experiment  evaluates  the 
Foldable  Integrated  Thin-Film  Stiffened  Solar  Array  (FITS  Solar  Array)  from 
MicroSat.  The  second  experiment  is  the  demonstration  of  Elastic  Memory  Composite 
(EMC)  Hinges,  donated  by  Composite  Technologies  Development  (CTD),  which  will 
deploy  a  panel  on  the  spacecraft.  Hinge  performance  during  the  initial  deployment 
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and  then  during  attitude  maneuvers  and  thermal  events  will  be  evaluated.  Third,  the 
slow-down  mechanism  of  the  gravity-gradient  boom,  an  in-house  design,  will  be 
tested.  The  slow-down  mechanism  will  be  evaluated  with  data  sent  wirelessly  from 
the  tip  mass  accelerometers  and  magnetometer  to  the  body  of  the  satellite. 

4  Mission  Objectives  and  Success  Criteria 

The  Mission  Objectives  and  their  success  criteria  are  defined  below.  Fulfilling  these 
in-flight  objectives  is  the  direct  responsibility  of  the  Mission  Operations  Team.  The 
MOPS  Team  methodology  for  achieving  these  objectives  is  outlined  in  section  6. 

4.1  Flight  Segment  Objectives  and  Criteria 

4.1.1  Assess  Deployment  Technologies 

The  objective  is  to  deploy  all  five  mechanisms  -  the  gravity  gradient  boom, 
the  Foldable  Integrated  Thin-Film  Stiffened  Solar  Array  (FITS),  the  two 
antennas  and  the  Composite  Technologies  Development  panel. 

The  criteria  for  success  are  the  full  deployment  of  the  gravity  gradient  boom, 
FITS  panel,  and  the  CTD  panel,  approximately  75%  of  the  on-board 
deployables.  The  antennas  constitute  the  remaining  25%,  and  are  considered 
less  mission-critical  because  they  will  still  function  if  they  are  not  deployed. 

4.1.2  Demonstrate  Stereo  Imaging 

The  objective  is  to  create  stereo  images  and  calculate  the  altitude  above  the 
ground  of  the  leading  and  trailing  edge  of  clouds,  and  a  topographical  map  of 
the  cloud’s  interior. 

The  success  criterion  is  to  complete  one  correct  topographical  map.  This  must 
be  verified  by  downloading  the  appropriate  pictures  and  confirming  that  the 
correct  altitude  of  the  cloud  edges  was  calculated  within  ±  500  meters. 

4.1.3  Demonstrate  Intelligent  Operations 

The  objective  is  to  demonstrate  that  the  satellite  can  evaluate  its  environment 
and  respond  accordingly. 

The  criterion  for  success  is  that  the  satellite  reacts  properly  and  autonomously 
at  least  one  time.  This  will  be  proven  by  examining  downloaded  spacecraft 
logs. 

4.2  Ground  Segment  Objectives  and  Criteria 

4.2.1  Demonstrate  two-way  communication  with  DINO 

The  objective  is  to  successfully  transmit  and  receive  information  from  the 
spacecraft. 
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The  criterion  for  success  is  that  95%  of  data  sent  by  either  the  ground 
station  or  DINO  is  received  by  the  other  system. 


4.2.2  Display  Telemetry 

The  objective  is  to  graphically  show  health  and  status  information.  The 
data  will  be  graphed  over  time,  and  easily  compared  to  simulated 
telemetry.  The  comparison  between  the  actual  and  simulated  telemetry  is 
particularly  critical,  to  identify  potential  problems  with  the  Mission 
Module  (MM). 

The  criterion  for  success  is  the  GUI  sending  commands  to  the  spacecraft 
and  displaying  Health  and  Status  (H&S)  data. 

4.2.3  Download  and  Distribute  Science  Data 

The  ground  software  must  automatically  handle  incoming  science  data 
from  the  satellite.  It  will  downlink  the  data,  make  it  available  to  the 
Science  Team  for  confirmation  and  further  analysis,  and  then  post  the  data 
in  an  online  database  for  public  access. 

The  instrumentation  readings  of  the  various  onboard  experimental 
mechanisms  will  similarly  be  obtained  and  evaluated,  then  distributed  to 
the  experiment’s  primary  investigators  via  a  secure  online  database. 

The  criterion  for  success  is  the  successful  distribution  of  raw  and  analyzed 
data  to  the  appropriate  people  and  databases. 

5  Operations  Systems  Overview 

5.1  Ground  Software  System 

The  software  simulator,  the  graphical  users  interface  (GUI),  the  communications 
software,  and  the  data  management  and  distribution  software  (DMDS) 
collectively  composes  the  Ground  Software  System. 

5.1.1  Software  Simulator 

The  software  simulator  provides  accurate  simulation  of  the  satellite  on  the 
ground.  This  simulation  capability  allows  the  Mission  Operations  Team  to 
validate  new  procedures,  Mission  Modules,  software  upgrades,  and  train  new 
Mission  Operators  on  the  behavior  of  the  satellite.  Like  most  simulators,  it  is 
composed  of  a  number  of  software  tools.  The  interaction  of  these  elements  is 
displayed  in  Figure  1. 

The  Simulator  uses  the  Flight  Software,  the  Mission  Module,  and  a  separate 
Python-based  Simulation  Module,  and  finally  Satellite  Tool  Kit  (STK)  from 
Analytical  Graphics,  Inc.  (AGI).  The  Simulation  Module  contains  the 
algorithms  to  simulate  most  of  the  telemetry  of  the  spacecraft,  and  STK 
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supplies  some  environmental  information,  such  as  simulated  magnetometer 
readings. 

The  Flight  Software  and  Mission  Module  are  identical  to  the  flight  versions; 
however  newer  versions  of  either  the  Flight  Software  or  Mission  Module  can 
be  inserted  for  testing.  The  Simulation  Module  is  a  Python-based  program  that 
returns  varying  values  to  the  Flight  Software.  These  values  are  based  on  the 
predicted  conditions  in  space,  such  as  temperature,  and  the  normal  hardware 
status  like  voltage  and  current  monitors.  Some  specific  values  are  delivered  to 
the  Simulation  Module  from  Satellite  Tool  Kit,  such  as  magnetometer 
readings  for  the  spacecraft’s  current  position,  and  updated  Two-Line  Elements 
(TLE).  Additionally,  STK  will  provide  a  three  dimensional  view  of  the 
spacecraft’s  position  and  attitude,  based  on  the  ADCS  module  within  the 
Flight  Software.  STK’s  graphical  display  capability  is  designed  to  give  the 
Mission  Operators  an  instinctive  feel  for  DINO’s  current  state. 


Figure  1:  Simulator  Flow  Chart 


5. 1 .2  Graphical  User  Interface 

The  Graphical  User  Interface,  developed  by  DINO’s  Software  Team,  allows 
Mission  Operators  a  fast  and  intuitive  way  to  display  telemetry  and  transmit 
commands  to  the  spacecraft.  The  GUI  is  written  in  Python,  to  ease  integration 
with  the  rest  of  the  software  components.  Notably,  the  GUI  can  accept 
telemetry  from  the  actual  spacecraft,  and  any  number  of  simulators.  Although 
the  GUI  is  termed  an  interface,  it  contains  all  the  functionality  associated  with 
the  user  interface.  The  GUI  alone  can  send  commands  to  the  satellite  and  the 
other  parts  of  the  Ground  Software  System.  For  a  screenshot  of  the  GUI,  see 
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Figure  2.  It  should  be  noted  that  Figure  2  represents  the  most  basic 
functionality  implemented  thus  far. 

Telemetry  is  displayed  in  graphical  and  tabular  forms  for  the  operator.  Graphs 
can  have  several  data  sets  overlaid  on  each  other  from  any  running  simulators 
and  the  telemetry  transmitted  from  the  satellite.  Additionally,  by  clicking  on 
the  graph,  the  user  is  presented  with  the  exact  value  at  that  time,  and  the 
option  to  list  commands  executed  before  and  after  that  time,  within  a  user- 
specified  boundary.  The  GUI  functionality  allows  the  operator  to  compare 
commands  with  associated  sensor  values.  Combined  with  the  3D 
representation  in  STK,  the  operator  should  have  an  intuitive  grasp  whether  or 
not  the  telemetry  is  reasonable.  For  example,  if  a  temperature  sensor  spikes, 
the  command  log  and  the  3D  representation  can  be  examined  quickly  to 
determine  either  a  cause  for  the  spike  or  to  conclude  that  it  was  a  suspect 
sensor  reading. 

The  GUI  allows  the  operator  to  command  the  spacecraft.  Each  subsystem  has 
its  own  display  containing  current  status  and  a  list  of  commands  and  activities. 
Activities  are  higher-level  functions  that  the  operator  can  perform,  and  each 
activity  is  composed  of  a  list  of  detailed  commands  that  will  accomplish  that 
activity.  For  example,  an  operator  might  want  to  disable  the  automatic  ADCS 
system  in  the  case  of  an  error.  That  would  constitute  an  activity,  and  the  GUI 
would  provide  a  time-ordered  list  of  low-level  commands  needed  to 
accomplish  the  activity.  The  operator  can  choose  activities  to  send  to  the 
satellite,  and  the  GUI  will  display  a  more  detailed  list  of  actual  commands  that 
will  be  sent  to  the  spacecraft.  The  GUI  does  have  an  error-checking  capability 
in  which  it  inspects  actions  and  commands  requested  by  the  user  for  validity, 
and  informs  the  user  if  there  is  a  potential  problem  with  that  command  or 
activity. 
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5. 1 .3  Communications  Software 

The  communication  software  bridges  the  gap  between  the  rest  of  the  ground 
software  and  the  satellite  through  the  ground  communications  hardware.  It 
controls  and  manages  the  radio  link  from  the  ground  to  the  spacecraft,  and 
performs  the  initial  data  management. 

Radio  link  management  consists  of  setting  or  changing  uplink  and  downlink 
frequencies  on  the  ground,  monitoring  signal  strength,  and  informing  the  user 
of  acquisition  and  loss  of  signal  (AOS  and  LOS,  respectively). 

Data  management  in  the  Communications  Software  is  strictly  concerned  with 
assembling  packets,  resolving  packet  errors,  and  assembling  data  from 
multiple  ground  stations  into  one  consistent  data  set. 

5.1.4  Data  Management  and  Distribution  Software 

The  Data  Management  and  Distribution  Software  (DMDS)  distributes 
telemetry  into  the  appropriate  databases  and  informs  operators  and  users  of 
telemetry  availability.  For  example,  it  routes  health  and  status  data  to  the 
health  and  status  database,  deployable  technology  data  to  the  secured  online 
database,  and  stereo  imaging  data  first  to  the  Imaging  Team  for  release,  then 
to  the  public  online  database. 

5.2  Flight  Software  System 

The  Flight  Software  System,  FSS,  is  primarily  the  responsibility  of  the  Software 
Team,  so  its  functionality  will  only  be  discussed  here  as  it  is  relevant  to  Mission 
Operations.  (See  DINO-SW-RPT-SW) 
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There  are  four  primary  segments  of  the  FSS  (See  Figure  3).  First,  there  is  the 
Linux-based  operating  system,  which  provides  the  interface  between  commands 
and  the  actual  hardware.  Second,  there  is  the  Error  Detection  and  Correction 
(EDC)  module  which  is  run  by  the  operating  system  to  check  for  errors, 
particularly  bit  flips  from  radiation.  Third,  there  is  the  spacecraft-unique  flight 
software,  a  module  written  in  Python  that  contains  the  detailed  information  about 
the  spacecraft  systems,  and  contains  the  algorithms  to  run  the  Mission  Module. 
Fourth,  there  is  the  Mission  Module  (MM)  itself.  The  MM  contains  all  the 
information  necessary  for  the  spacecraft’s  autonomous  operations,  and  is  the 
responsibility  of  Mission  Operations.  It  will  be  discussed  in  depth  below. 


The  Mission  Module  (Figure  4)  is  based  around  Observable  Values,  Rules,  and 
Scripts.  Observable  Values  are  variables  that  describe  the  state  of  a  particular  part 
of  the  spacecraft,  for  example  the  current,  voltage,  and  thermocouple  sensors. 
Rules  are  objects  that  monitor  a  particular  observable  value  for  changes.  When 
the  observable  value  changes,  the  rule  executes  a  script  to  react  to  that  changing 
value.  A  script  is  a  set  of  commands  to  the  Flight  Software  to  respond  to  the 
current  situation.  These  scripts  can  activate  or  deactivate  rules,  create  or  remove 
observable  values,  and  scripts  can  command  spacecraft  hardware.  See  DINO-SW- 
RPT-SW  for  more  information. 
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Flight  Software 


Figure  4:  Mission  Module  Architecture 


6  Mission  Operations  Functions 

The  Mission  Operations  Team  has  many  functions  to  perform  before,  during,  and 
after  the  mission.  These  are  given  in  detail  in  sections  6. 1-6.8,  and  summarized  in 
Table  1,  below.  Each  function  is  detailed,  with  the  party  responsible  for  the 
supervision  of  each  function  given  last. 

6.1  Operations  Planning 

Operations  Planning  consists  of  the  pre-launch  activities  that  define  how  Mission 
Operations  will  function  during  flight.  This  requires  a  thorough  understanding  of 
the  spacecraft  mission,  systems,  and  objectives.  The  Operations  Planning  function 
provides  a  Mission  Timeline  before  the  launch  that  outlines  what  activities  and 
objectives  are  part  of  each  mission  phase.  See  Section  7  fore  more  information  on 
the  Mission  Timeline. 

There  are  a  number  of  decisions  that  must  be  made  before  launch,  with  regard  to 
Operations.  Resources  must  be  identified,  scheduled,  and  managed  to  ensure  the 
right  people  and  equipment  are  available  when  needed.  The  level  of  spacecraft 
automation  must  be  decided.  The  post-launch  spacecraft  functions  must  be 
identified,  and  responsibility  for  each  function  clearly  delineated.  Finally  any 
needed  software  must  be  created  and  tested  with  the  spacecraft  hardware,  and 
personnel  trained  in  its  use. 

For  DINO,  pre-launch  Operations  Planning  consists  of  extensive  simulation  to 
characterize  the  day-to-day  activities  of  the  satellite.  These  simulations  are  called 
Day  In  The  Life  (DITL)  Tests.  DITL  Tests  incrementally  evaluate  the  software 
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and  hardware  interactivity,  culminating  in  several  week-long  tests  that  simulate 
the  actual  spacecraft  operations.  The  longest  tests  draw  together  all  the  flight  and 
ground  elements  together  for  the  first  time,  ensuring  that  all  of  them  function  well 
independently  and  together. 

Operations  Planning  is  performed  by  the  MOPS  Team,  and  is  the  responsibility  of 
the  MOPS  Team  Lead. 

6.2  Activity  Scheduling  and  Development 

Prior  to  launch,  Activity  Scheduling  and  Development  (ASD)  is  responsible  for 
formulating  the  standard  procedures  to  be  used  throughout  the  mission  lifetime. 
The  procedures  must  be  verified  through  simulation  with  the  entire  set  of  ground 
and  flight  components.  ASD  assists  Operations  Planning  in  formulating  the 
details  of  procedures. 

During  Flight,  ASD  further  refines  existing  procedures  and  creates  new 
procedures  to  accomplish  unforeseen  activities  or  objectives.  All  procedures  are 
to  be  simulated  prior  to  use,  and  inspected  and  approved  by  the  Systems  Team 
Lead,  the  Mission  Operations  Team  Lead,  and  the  Team  Lead(s)  of  the  system(s) 
involved  with  each  procedure.  Each  modification  of  an  existing  procedure  is 
likewise  subjected  to  further  review. 

This  function  is  performed  by  the  Mission  Operations  Team,  and  is  personally 
supervised  by  the  MOPS  Team  Lead. 

6.3  Mission  Control 

Mission  Control  is  the  day-to-day  maintenance  and  operation  of  the  satellite. 
Mission  Control  is  responsible  for  executing  the  various  procedures  needed  to 
keep  the  spacecraft  operational,  monitor  the  spacecraft  for  errors  and  anomalies, 
and  instigate  other  MOPS  functions  as  needed. 

Mission  Control  for  the  DINO  mission  will  be  staffed  by  undergraduate  or 
graduate  students,  trained  on  the  satellite  and  ground  software.  The  student  pool 
will  be  separated  into  teams  of  three  each,  called  Mission  Control  Teams  (MCT), 
assembled  with  regard  to  similar  scheduling  availability.  Each  team  will  be 
composed  of  a  Supervisor,  an  Analyst,  and  a  Communications  Engineer  (CE). 

The  supervisor  is  responsible  for  maintaining  the  proficiency  of  the  team, 
ensuring  each  member  is  on  time  for  shifts,  planning  activities  during  pass  times, 
and  identifying  anomalies,  with  the  help  of  the  other  team  members.  The 
supervisor  is  required  to  have  an  in-depth  knowledge  about  the  satellite  and 
ground  systems. 

The  Analyst  operates  the  Graphical  User  Interface  in  the  Ground  Software  System 
to  identify  anomalies  in  the  operation  of  the  satellite,  identify  if  possible  the 
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causes  of  any  anomalies,  and  alerts  the  supervisor  to  any  potential  problems.  The 
Analyst  sends  commands  to  the  spacecraft  via  the  GUI. 

The  Communications  Engineer  (CE)  starts  and  monitors  the  entire  chain  required 
to  successfully  communicate  with  the  satellite.  The  CE  predicts  pass  times  and 
durations,  and  alerts  the  supervisor  to  each  pass.  During  the  pass  the  CE  provides 
the  team  a  countdown  of  the  remaining  time.  The  Communications  Engineer 
additionally  monitors  the  connectivity  from  the  satellite  to  the  ground  stations, 
along  with  the  link  to  each  database  and  to  the  GUI. 

During  the  mission,  the  Mission  Operations  Center  (MOC)  will  be  staffed  by  a 
MCT  for  each  pass.  The  MOC  will  have  a  graphic  representation  of  the  satellite 
state,  shown  from  STK,  projected  onto  a  screen.  Basic  spacecraft  health  and  status 
information  will  be  displayed  here  as  well,  to  increase  the  overall  situational 
awareness  of  the  MCT. 

This  function  is  performed  by  the  Mission  Operations  Team,  and  is  the 
responsibility  of  the  MOPS  Team  Lead  to  supervise. 

6.4  Data  Services 

Data  Services  is  strictly  concerned  with  assembling,  verifying,  and  routing  data 
from  the  satellite  to  the  eventual  data  user.  As  data  is  downloaded  from  the 
satellite,  whether  it  is  health  and  status  data,  science  data  and  imagery,  or 
experiment  data,  Data  Services  is  responsible  for  archiving  the  data  in  the 
appropriate  database,  and  informing  interested  parties  of  the  data  delivery  and 
content. 

Assembly  and  verification  of  the  data  involves  receiving  the  data  from  one  or 
more  ground  stations,  assembling  the  multiple  data  streams  into  one  coherent  data 
set,  and  then  verifying  the  contents  of  the  data  is  not  corrupted  or  incomplete. 

Data  routing  is  essentially  archiving  the  data,  then  providing  that  data  to 
whomever  needs  it.  Each  type  of  information  is  treated  differently.  Health  and 
Status  data  must  be  archived  in  a  database,  and  made  available  to  the  Ground 
Software  for  display. 

Science  data  must  similarly  be  archived,  and  forwarded  to  the  Science  Team  for 
inspection  and  eventual  release  to  the  public.  DINO’s  determination  of  cloud 
altitude  may  be  potentially  useful  for  meteorologists,  giving  this  particular  type  of 
data  an  added  delivery  time  requirement.  To  meet  this  delivery  time  constraint, 
the  results  of  DINO’s  onboard  analysis  will  be  automatically  made  available  to 
the  public,  after  the  system’s  initial  verification.  Continued  verification  of  the 
onboard  analysis  is  made  by  the  Science  Team,  by  comparing  DINO’s  analysis 
with  the  images  used  in  the  analysis,  essentially  the  Science  Team  will  spot-check 
the  process. 
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Experiment  data,  from  the  EMC  Hinges,  the  FITS  Solar  Array,  and  the  Ball 
power  system  design  must  be  archived  in  a  secure  database,  and  the  appropriate 
primary  investigators  informed  of  its  availability.  This  data  may  be  made  publicly 
available,  at  the  discretion  of  the  primary  investigators. 

This  function  is  performed  by  the  automated  ground  software,  and  is  the 
responsibility  of  the  MOPS  Team  Lead  to  supervise,  with  the  help  of  CSGC 
Network  System  Administrators. 

6.5  Navigation  and  Attitude  Control 

DINO’s  Attitude  Determination  and  Control  System  (ADCS)  is  designed  to 
operate  autonomously.  To  maintain  the  necessary  accuracy  with  the 
magnetometer,  the  on-board  propagator  must  be  given  updated  Two-Line 
Elements  approximately  every  two  weeks.  (See  DINO-ADCS-RPT-ADCS) 

If  the  closed-loop  autonomous  ADCS  system  above  fails,  it  becomes  the 
responsibility  of  the  Mission  Operation  Team  to  handle  Attitude  Control.  This 
will  be  done  via  an  open-loop  form  of  the  ADCS  system,  implemented  in  the 
Mission  Module.  This  option  gives  some  degraded  performance,  and  is 
considered  a  temporary  alternative  until  the  closed-loop  system  is  operational. 

This  function  is  performed  by  the  Mission  Operations  Team,  and  is  the 
responsibility  of  the  Mission  Operations  Team  Lead,  and  additionally  is 
supervised  by  the  ADCS  Team  Lead. 

6.6  Spacecraft  and  Payload  Operations 

Spacecraft  and  Payload  Operations  is  the  function  that  is  responsible  for 
responding  to  serious  operational  problems  with  either  the  spacecraft  or  payload. 
These  types  of  problems  are  generally  outside  the  knowledge,  training  and 
procedures  of  the  Mission  Operations  Team,  and  require  a  more  detailed 
knowledge  of  the  satellite  systems. 

The  process  associated  with  Spacecraft  and  Payload  Operations  is  initiated  when 
the  MCT  Supervisor  on  duty  recognizes  a  potentially  serious  problem  with  the 
satellite  and  contacts  the  MOPS  Team  Lead.  If  the  MOPS  Team  Lead  determines 
that  the  problem  needs  more  information  than  the  MOPS  Team  has,  then  the 
Team  Lead  contacts  the  designated  Systems  Team  personnel,  and  the  involved 
subsystem  Team  Leads,  or  associated  experts.  This  group  assembles,  diagnoses 
the  problem,  and  recommends  the  appropriate  course  of  action.  Once  the  proper 
action  has  been  decided,  it  is  the  responsibility  of  the  Mission  Operations  Team 
Lead  to  ensure  that  it  is  carried  out. 

This  function  is  performed  by  the  Mission  Operations  Team,  the  requisite  system 
experts,  and  is  supervised  by  the  Mission  Operations  Team  Lead. 
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6.7  Mission  Assurance  and  Risk  Mitigation 

Mission  Assurance  and  Risk  Mitigation  (MARM)  is  the  function  that  ensures  the 
satellite  will  continue  to  function.  Mission  Assurance  focuses  on  achieving  the 
mission  objectives,  and  Risk  Mitigation  is  how  those  objectives  are  achieved  with 
minimum  risk  to  the  spacecraft. 

Part  of  this  effort  is  the  spacecraft’s  autonomous  control  system,  the  Mission 
Module.  The  MM  relies  on  the  interaction  of  its  components  to  guide  the  activity 
of  the  satellite.  The  combinations  of  rules  and  sensors  allow  the  flexibility  for 
basic  autonomy,  but  the  dangers  are  that  the  Mission  Module  may  behave  in  an 
unpredictable  or  improper  way  and  that  the  reaction  to  a  particular  situation  could 
exacerbate  a  problem  rather  than  resolve  it.  The  solution  to  this  is  two-fold,  first 
the  Mission  Module  must  be  rigorously  tested  in  a  simulated  environment,  and  the 
rest  of  the  Flight  Software  must  impose  some  limited  oversight  on  the  Mission 
Module’s  activities,  much  the  same  as  inhibitors  prevent  hardware  from  doing 
certain  activities. 

Another  part  of  the  process  for  MARM  is  the  certification  of  operations  personnel 
and  the  validation  of  procedures.  Certification  is  outlined  in  section  6.8  below. 
Procedure  validation  ensures  that  any  commands  sent  to  the  spacecraft  are  valid, 
without  relying  on  the  ground  software  to  catch  potential  errors. 

This  function  is  performed  by  the  various  Team  Leads,  and  is  the  responsibility  of 
the  Mission  Operations  Team  Lead,  with  supervision  by  the  Project  Manager  and 
Systems  Team  Lead. 

6.8  Operator  Training  and  Certification 

The  Mission  Operations  Team  is  largely  responsible  for  recruiting,  training  and 
certifying  its  personnel.  Several  teams  must  be  formed  to  ensure  staffing  of  the 
Mission  Operations  Center  during  pass  times  and  around  school  scheduling.  The 
personnel  pool  for  Mission  Operations  consists  of  students  at  the  University  of 
Colorado,  and  is  untrained  in  the  specifics  of  operating  a  satellite,  for  the  most 
part.  This  requires  an  intensive  training  period  of  several  months  to  bring  each 
person  up  to  speed  on  the  fundamentals  of  the  DINO  mission,  and  then  further 
training  in  each  of  the  specialties  needed  for  each  team. 

The  training  coursework,  materials,  and  certification  requirements  are  outlined 
during  Day  In  The  Life  Testing.  Simulation  is  integrated  into  the  training  course, 
with  an  emphasis  on  performing  basic  operations,  and  trouble-shooting  the 
satellite  through  sufficiently  detailed  technical  knowledge. 

The  certification  process  is  two-fold.  First,  an  individual  receives  the  Basic 
Certification,  which  introduces  them  to  DINO  as  a  whole  system  and  prepares 
them  for  any  position  within  the  MCT.  Once  someone  has  the  Basic  Certification, 
they  can  become  certified  for  any  or  all  of  the  three  positions  within  the  MCT. 
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Each  of  these  positions  requires  detailed  knowledge  of  a  particular  part  of  the 
DINO  mission. 

The  Basic  Certification  requires  the  individual  to  be  able  to  recall  with  reasonable 
accuracy  a  functional  block  diagram  of  the  Flight  and  Ground  Systems.  The 
individual  must  demonstrate  familiarity  with; 

1 .  The  responsibilities  of  each  specialty  position 

2.  The  set  up  and  verification  of  each  specialty’s  station 

3.  The  Ground  Software  System  GUI 

4.  The  basic  day  to  day  operations  of  the  satellite 

5.  The  various  procedures  used  to  control  the  spacecraft. 

The  second  level,  Specialty  Certification,  specifies  that  the  individual  is  qualified 
to  run  a  particular  position  in  the  MCT,  whether  it  is  Supervisor,  Analyst,  or  CE 
(See  6.3).  Each  specialty  requires  a  unique  understanding  of  DINO,  and  each  are 
outlined  briefly  below; 

The  Supervisor  must  be  able  to: 

1.  Plan  activities  and  objectives  for  each  pass  opportunity 

2.  Operate  either  of  the  other  positions  with  reasonable  proficiency 

3.  Lead  the  MCT  effectively 

4.  Communicate  information  clearly  to  the  MOPS  Team  Lead  and 
Project  Manager. 

5.  Demonstrate  a  deep  understanding  of  the  satellite  systems 

6.  Demonstrate  proficiency  in  trouble-shooting  problems  through 
technical  knowledge 

The  Analyst  must  be  able  to: 

1 .  Demonstrate  proficiency  with  the  Ground  Software  GUI 

2.  Demonstrate  a  working  knowledge  of  the  Mission  Module. 

3.  Demonstrate  proficiency  in  spotting  spacecraft  anomalies. 

4.  Demonstrate  fundamental  understanding  of  the  procedures  used  to 
operate  the  satellite. 

The  Communications  Engineer  must  be  able  to: 

1.  Demonstrate  understanding  of  the  subtleties  of  the  Ground  Software 
System 

2.  Demonstrate  proficiency  in  trouble-shooting  problems  with  the 
Ground  Software  System 

3.  Demonstrate  a  working  knowledge  of  the  capabilities  and  limitations 
of  the  Software  Simulators. 

4.  Demonstrates  sufficient  knowledge  of  STK  to  accurately  predict  pass 
Acquisition  of  Signal  times  and  pass  durations. 

5.  Demonstrate  sufficient  knowledge  of  Data  Services  to  ensure  it  is 
working  properly 

6.  Demonstrate  the  ability  to  trouble-shoot  problems  in  Data  Services. 
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These  are  the  most  basic  areas  that  training  and  certification  covers  for  the  DINO 
Mission  Operations  Team.  Care  must  be  taken  in  designing  the  particulars  of  the 
training  schedule  and  content  to  allow  for  the  inexperience  of  student  operators. 


Table  1:  Mission  Operations  Functions 


MOPS 

Function 

Where  Accomplished 

Responsibilities  Inputs  Outputs  „  _ 

Board  Ground 

S/C 

Mission 

Planning 

Activity 
Planning  & 
Development 

Mission 

Control 

Data  Services 

Navigation  & 
Attitude 
Control 

Spacecraft  & 
Payload 
Operations 

Mission 
Assurance  & 
Risk 

Mitigation 

Operator 
Training  & 
Certification 

Deployables  and 
science  mission 
planning 

Deployables 

requirements 

Deployables 

schedule, 

Mission  Timeline, 
Training  Materials, 
Operations  Plan, 
DITL  Testing, 
Software 
Requirements 

Operator  with 
automated 
software  support 

Ground  and  S/C 
scheduling 

Ground  and 

S/C 

requirements 

Procedures, 
schedules  and 
objectives 

Htf 

Monitor  S/C 
health  and 
status,  perform 
maintenance 

Telemetry  and 

command 

requests, 

TLEs 

Pass  reports,  real¬ 
time  commands 

Operator  with 
automated 
software  support 

Gathering, 
managing,  and 
distributing 
mission  data 

S/C  H&S, 
science 
payload  and 
experiments 
data 

Accessible  database 
of  historical  H&S, 
science  & 
experiment  data 

Data 

gathered 

and 

packaged 

Recv.  from  S/C, 
stored  in  DB 
distributed  via 
internet  to  users 

ADCS  duties 

Orbit  TLEs 

ADCS  control 
outputs 

ADCS/ 

MM 

Acquire  TLEs 
and  update  on 

S/C 

Analyze 

anomalies, 

payload  and 

system 

engineering 

calibrations 

S/C  and 

Payload 

engineering 

data 

Anomaly  responses, 
command  requests 

S/C  design  team 

Validation  of 
procedures,  MM 
&FSW 
upgrades 

Proposed 
improvements 
and  activities 

Approval  or 
recommendations 

Subsystem 
Specialists  and 
Team  Leads 

Obtaining, 
Training,  & 
Certifying 
Operators 

Untrained 

Personnel 

Certified  DINO 
Mission  Operators 

Mission 

Operations 

Team 

7  Mission  Timeline 

The  DINO  Mission  Timeline  outlines  the  sequence  of  major  events  for  each  phase  of 
operation.  The  schedule  is  objective-driven,  rather  than  a  strict  schedule.  In  other 
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words,  the  objectives  are  accomplished  when  it  is  reasonably  possible,  rather  than  as 
soon  as  possible. 

There  are  four  phases  to  the  mission;  Beginning  of  Life  (BOL),  Nominal  Operations 
(NOMOPS),  Standby,  and  End  of  Life  (EOL).  Each  phase  represents  a  substantial 
step  forward  in  the  progression  of  the  mission.  Each  step  has  its  own  version  of  the 
Mission  Module,  to  focus  the  autonomous  operations  of  the  satellite  safely  and 
appropriately. 

In  each  section  below,  the  flight  and  ground  objectives  are  discussed  and  presented  in 
a  table,  and  the  Mission  Module  functionality  at  this  point  is  outlined. 

7 . 1  Beginning  of  Life 

The  Beginning  of  Life  (BOL)  phase  starts  at  launch,  and  continues  until  all 
systems  in  both  the  flight  and  ground  segments  are  verified  and  certified  for 
nominal  operations. 

The  flight  objectives  for  this  phase  are  largely  deploying  the  various  mechanisms 
as  possible,  establishing  radio  contact  with  the  satellite,  and  verifying  spacecraft 
health  and  status.  Every  subsystem  of  the  spacecraft  will  have  its  own  verification 
checklist  that  details  the  functionality  to  be  tested,  and  the  satellite  will  run  a 
series  of  ground-initiated  exercises  to  test  the  overall  system  capabilities.  See 
Table  2  for  a  summary  of  the  objectives. 

The  Mission  Module  at  this  phase  of  the  mission  does  comparatively  little,  polling 
and  logging  sensor  values  at  a  slightly  faster  pace  than  normal  to  obtain  coverage 
across  the  orbit.  Science  functionality  is  limited  to  allowing  the  ground  to  verify 
that  the  onboard  algorithms  are  functioning  properly.  It  will  contain  the 
verification  exercises  discussed  above,  and  will  mn  these  upon  command  from  the 
ground. 

The  ground  objectives  consist  of  the  overall  ground  segment  verification, 
continuing  operator  training,  and  updating  the  simulators.  The  update  of  the 
spacecraft  simulators  is  a  particularly  critical  objective.  This  activity  involves 
reprogramming  the  ground  simulation  software  to  more  closely  match  the 
nominal  conditions  in  space.  The  BOL  phase  gives  us  the  chance  to  determine 
what  “nominal”  really  means  for  DINO.  The  update  allows  the  Mission  Modules 
to  be  better  tested  and  rewritten  and  makes  it  considerably  easier  for  Mission 
Operators  to  use  those  simulation  values  to  spot  potential  anomalies  on  the 
spacecraft.  Finally,  with  a  more  realistically  tested  Mission  Module,  the  next 
phase  of  the  mission  can  safely  continue,  to  the  Nominal  Phase. 
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Table  2:  Beginning  of  Life  Activities 


■ 

Objective 

Timing 

(Mission  Start  Time/Duration) 

■ 

FLT 

Antenna  Deployment 

Post  Separation  or  -1000  sec  / 
~30  sec 

2 

FLT 

ADCS  Detumble 

-1500  sec  /  -2000  sec 

3 

FLT/ 

GND 

Establish 

Communications 

First  Pass  /  -7  minute  pass 

zm 

FLT/GND 

Determine  S/C  Health 

First  Opportunity  /  NA 

5 

FLT/GND 

Verify  S/C  Systems 

First  Opp.  /  Unknown 

6 

FLT 

Boom  Deployment 

First  Opportunity  /  Unknown 

n 

FLT 

FITS  Deployment 

First  Opp.  /  Unknown 

8 

FLT 

CTD  Deployment 

First  Opp.  /  Unknown 

9 

GND 

S/C  Sensor  Calibration 

Multiple  Passes  /  Unknown 

10 

GND 

Update  S/C  Simulators 

Unknown  /  Unknown 

11 

GND 

Operator  Training 

Continuous 

7.2  Nominal  Operations 

The  Nominal  Operations  phase  of  DINO’s  mission  is  the  day-to-day  standard 
operation  of  the  satellite.  In  this  phase,  all  satellite  systems  have  been  verified, 
and  any  problems  within  the  flight  or  ground  segments  of  the  mission  have  been 
solved.  See  Table  3  for  a  list  of  objectives  in  this  phase. 

There  are  fairly  few  nominal  objectives,  but  each  has  a  board  scope.  Science  and 
Experiment  investigations  constitute  the  bulk  of  the  work.  The  onboard  analysis 
of  images  will  continue  to  be  updated  as  possible.  The  FITS  Solar  Array,  the 
Shape  Memory  Composite  Hinges,  and  the  gravity  gradient  boom  will  all  be 
constantly  monitored  and  evaluated.  In  the  case  of  the  boom,  the  battery  life  on 
the  tip  mass  will  limit  the  availability  of  this  data  to  a  short  window.  In  particular 
the  FITS  Solar  Array  and  the  EMC  Hinges  are  targeted  for  testing  during  thermal 
snaps  and  attitude  maneuvers. 

The  Intelligent  Operations  aspect  of  the  mission  will  be  explored ,  with 
increasingly  complex  Mission  Modules,  designed  to  maximize  the  autonomy  of 
DINO.  The  Modules  will  continue  to  be  developed  in-house,  with  the  aid  of 
software  experts. 

As  a  housekeeping  duty,  the  onboard  propagator  will  be  periodically  updated  with 
new  Two  Line  Elements  (TLE)  that  allows  the  propagator  to  better  predict  the 
current  position  of  the  satellite,  and  increase  the  accuracy  of  the  ADCS  system. 

In  keeping  with  the  spirit  of  the  CSGC,  DINO  will  be  increasingly  visible  and 
open  to  the  public,  with  frequent  tours  of  the  facility,  demonstrations  and 
presentations.  These  activities  are  designed  to  show  the  next  generation  of 
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students  the  possibilities  and  challenges  of  engineering  for  space  applications,  and 
encourage  all  ages  to  further  explore  science  and  mathematics. 


Table  3:  Nominal  Operations 


Objective 

Type 

Objective 

Timing 

(Mission  Start  Time/Duration) 

1 

FLT 

Science 

Continuous 

2 

FLT/GND 

MM/FSW  Upgrades 

Continuous 

3 

FLT 

Experiment  Investigations 

Continuous  /  Maneuvers 

4 

FLT 

ADCS  TLE  Updates 

Continuous  /  -Every  2  weeks 

5 

GND 

Increased  Public  Outreach 

Continuous 

7.3  Standby 

The  Standby  Phase  is  a  type  of  operations  where  the  spacecraft  is  set  up  to  survive 
as  long  as  possible  at  a  very  basic  level.  This  stage  will  occur  in  the  event  that  the 
spacecraft  has  experienced  a  serious  onboard  anomaly,  or  may  be  ordered  into 
this  state  to  preserve  battery  life. 

Standby  is  characterized  by  no  science  activity,  the  minimum  attitude  control,  and 
minimum  communications  with  the  ground. 

7.4  End  of  Life 

The  End  of  Life  (EOL)  phase  occurs  when  the  satellite  is  no  longer  capable  of 
sustained  nominal  operations.  Depending  on  the  circumstances,  DINO  will 
eventually  bum  up  in  Earth’s  atmosphere.  If  the  satellite  is  alive  during  this  time, 
the  ADCS  system  will  take  as  many  readings  as  possible,  to  characterize  the  final 
time  of  the  satellite.  On  the  ground,  the  mission  will  be  followed  by  the  Post 
Mission  Review,  where  the  entire  mission  is  scmtinized  with  hindsight  to 
determine  what  went  well,  what  needed  improvement,  and  what  future 
applications  DINO’s  systems  could  support. 

Table  4:  End  of  Life 


■ 

Objective 

Timing 

(Mission  Start  Time/Duration) 

H 

FLT 

Increased  ADCS 
Readings 

EOL 

2 

FLT 

S/C  Destruction  in 
Atmosphere 

Unknown 

3 

GND 

Post-Mission 

Evaluation 

EOL 
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Appendix  A  -  List  of  Acronyms 

BOL:  Beginning  of  Life 

CSGC:  Colorado  Space  Grant  Consortium 

CTD:  Composite  Technologies  Development 

DINO:  Deployed  Intelligent  Nanosat  Operations 

EOL:  End  of  Life 

EMC:  Elastic  Memory  Composite 

FITS:  Foldable  Integrated  Thin-Film  Stiffened 

FLT:  Flight 

FSS:  Flight  Software  System 
GND:  Ground 

H&S:  Health  and  Status  Telemetry 

MARM:  Mission  Assurance  and  Risk  Mitigation 

MCT:  Mission  Control  Team 

MM:  Mission  Module 

MOC:  Mission  Operations  Center 

MOP:  Mission  Operations  Plan 

MOPS:  Mission  OPerationS  Team 

S/C:  Spacecraft 

STK:  Satellite  Tool  Kit 
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Appendix  B  -  Glossary 

Mission  Control  Team:  A  team  composed  of  a  Supervisor,  Data  Analyst,  and 
Communications  Engineer.  The  MCT  mans  the  Mission  Operations  Center  during  passes 
with  the  satellite,  and  is  responsible  for  sending  and  receiving  commands  and  data  with 
the  satellite. 

Mission  Module:  An  operator-written  set  of  rules  and  responses  that  govern  the 
autonomous  operation  of  the  satellite.  This  plugs  directly  into  the  flight  software,  where  it 
interacts  with  hardware  input  and  produces  the  appropriate  commands  for  the  flight 
software  to  execute. 

Python:  A  high-level  open-source  programming  language.  DINO  uses  Python  because  of 
its  ease  of  use,  fast  development  time,  and  compatibility  with  Linux.  See  DINO-FSW- 
RPT-FSW  and  tow. python.org  for  more  information. 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

Since  January  2003,  people  have  learned,  taught,  and  been  inspired  through  the 
DINO  program.  This  program  has  become  a  place  where  students  at  the 
University  of  Colorado  can  work  together  and  learn.  Industry  has  used  this 
spacecraft  as  a  platform  to  test  new  technologies  but  in  the  process  teach  the 
students  involved.  Finally,  university  students  have  brought  concepts  of  this 
program  and  space  to  K-12  students  around  the  state. 

This  document  will  highlight  the  involvement  of  people  over  the  last  two  years 
in  the  DINO  project. 

1 .5  Referenced  Documents 

None 


2  Student  Involvement 

A  total  of  102  undergraduate  and  graduate  students  at  the  University  of  Colorado  as 
well  as  two  high  school  students  from  Boulder  High  School  have  been  involved  with 
the  DINO  project  since  January  2003.  The  majority  of  students  that  begin  working 
with  Space  Grant  do  so  as  credit  students  or  volunteers.  The  University  of  Colorado 
offers  three  levels  of  independent  study  credit  to  students  including  both  upper  and 
lower  level  undergraduate  credit  as  well  as  graduate  credit.  Alternatively,  students 
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can  apply  for  paid  positions.  There  is  limited  availability  for  these  positions  and  so 
they  are  reserved  for  students  who  offer  exceptional  technical  or  leadership  skills. 
Furthermore,  these  positions  offer  only  about  half  the  salary  of  a  normal  engineering 
internship.  However,  internships  do  not  offer  students  the  opportunity  to  experience 
the  same  high-level  technical  challenges  and  leadership  responsibilities  as  Space 
Grant  can  offer.  In  summary,  Space  Grant  attracts  students  who  value  a  hands-on 
education  and  real-world  engineering  experience  beyond  what  the  classroom  or 
industry  can  offer  them. 

Space  Grant  does  not  keep  detailed  records  of  volunteer  students.  All  of  the  numbers 
below  revolve  around  students  who  were  paid  or  have  earned  credit.  The  majority  of 
the  data  has  been  taken  from  an  online  database  that  was  created  in  the  fall  of  2003. 
Because  of  this,  student  involvement  previous  to  the  fall  of  2003  is  not  completely 
accounted  for. 

2.1  Wide  Spectrum  of  Majors 

Students  from  seven  different  majors  have  been  involved  with  the  DINO 
project.  Those  majors  are  aerospace  engineering,  applied  math,  civil 
engineering,  computer  science,  electrical  and  computer  engineering, 
engineering  physics,  and  mechanical  engineering.  Additionally,  four  of  the 
students  have  not  reported  their  majors  to  Space  Grant.  Figure  1  below  is  a 
graph  showing  the  percentage  of  students  in  each  major. 


Figure  1:  Percentage  of  Majors 


2.2  Subsystems 

There  are  14  different  subsystems  on  DINO.  Below,  in  Figure  2,  is  a  graph 
showing  the  percentage  of  the  DINO  team  contributing  to  each  subsystem. 
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Several  students  have  worked  on  more  than  one  subsystem.  Each  student  was 
included  each  subsystem  that  they  participated  in. 


□  ADCS 

■ADCS  Cal. 

□  C&DH 

□  COMM 

■  MECH 

OMOPS  BPM 

□  Power 

■  Science 

B  Software 

□  Structure 

□  Systems 

■Thermal 

■  Tip  Mass 

Figure  2:  Subsystem  Percentages 


2.3  Paid  vs.  Credit  Students 

Below,  in  Figure  3,  is  a  graph  depicting  how  many  paid  students  there  are 
versus  how  many  credit  students. 


Page  6  of  14 


117  of  190 


DINO:  People  Involved 


DINO-PM-PRT-PEOPLE,  Rev.  A 


35 


Figure  3:  Number  of  Paid  vs.  Credit  Students 

2.4  Start  Dates  for  People 

As  expected  there  is  significant  turnover  at  the  transition  between  each 
semester.  Most  of  the  time,  this  is  a  result  of  students  graduating  and/or 
obtaining  jobs.  This  shows  that  Space  Grant  is  accomplishing  its  main 
objective,  which  is  to  prepare  students  for  their  careers.  One  trend  that  the 
project  was  pleased  with  is  that  most  students  involved  in  the  completion  of  the 
DINO  project  started  in  the  fall  of  2003.  This  means  that  DINO  was  able  to 
obtain  a  large  number  of  students  at  the  beginning  of  the  project  maintain  their 
interest  and  enthusiasm  until  its  completion. 
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□  Summer  2003 

■  1st  Semester  2003 

□  2nd  Semester  2004 
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Figure  4:  People’s  Start  Date 
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3  Industry  Involvement 

DINO  has  been  very  fortunate  in  the  amount  of  industry  involvement  with  the  project. 
Support  from  industry  has  ranged  from  hardware  donations,  monetary  donations,  real 
world  training,  and  in  many  cases  employment  opportunities.  Perhaps  the  most 
valuable  donation  is  the  mentorship  that  comes  with  each  of  these  generosities.  The 
industrial  relationships  have  proven  to  be  mutually  beneficial  to  both  Space  Grant  and 
the  donating  companies.  This  is  made  evident  by  the  fact  that  several  companies 
have  elected  to  support  Space  Grant  in  every  way  mentioned  above. 

Ball  Aerospace,  Composites  Technology  Development,  and  MicroSat  were  three  such 
companies  that  contributed  in  a  variety  of  ways.  Each  of  these  companies  donated 
hardware  while  also  providing  advising  and  employment  opportunities.  In  the  design 
of  DINO,  several  components  were  also  required  that  were  beyond  the  financial 
scope  of  the  project.  In  these  cases,  other  companies  were  contacted  for  donations. 
Many  were  more  than  happy  to  contribute  hardware  and  advising  such  as  TiNi, 
Starsys,  Planetary  Systems  Corporation,  and  Lockheed  Martin.  The  contributions  of 
each  company  are  expanded  on  below,  as  well  as  descriptions  of  the  relationship 
between  each  of  them  and  Space  Grant. 

3.1  Ball  Aerospace 

Ball  Aerospace  is  working  in  conjunction  with  the  DINO  team  on  the  power 
subsystem.  The  power  team  at  Ball  Aerospace  is  currently  developing  an 
innovative  method  for  packaging  power  systems  in  satellites.  Ball  engineers 
determined  that  working  with  students  to  develop  this  concept  would  be  a  more 
coSt-friendly  idea  than  pursuing  the  same  development  process  at  Ball.  The 
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original  concept  for  the  physical  portion  of  the  power  system  was  developed 
entirely  by  Ball  engineers.  Students  however,  accomplished  the  majority  of  the 
electrical  design.  During  the  design  process,  the  Ball  engineers  took  an 
advisory  role  to  the  Space  Grant  students  responsible  for  procuring  parts, 
building,  and  testing  the  system.  Ball  was  happy  enough  with  the  project  that 
many  of  the  Space  Grant  students  involved  with  it  were  offered  employment  as 
they  approached  graduation.  In  result,  many  students  had  the  unique 
opportunity  to  work  on  the  power  subsystem  from  both  the  Space  Grant  and  the 
Ball  perspective. 

Ball  Aerospace  was  very  generous  to  the  program  by  donating  hardware,  money 
for  hardware  and  student  salaries,  vibration  and  thermal  vacuum  testing,  and 
mentorship.  Out  of  everything  that  Ball  has  done  for  DINO,  the  mentorship  has 
been  the  most  valuable.  Once  a  week  two  to  four  Ball  engineers  would  come  to 
the  Space  Grant  offices.  The  original  purpose  of  these  meetings  was  to  go  over 
the  status  of  the  power  system  exclusively,  but  the  meetings  evolved  into  much 
more  as  the  Ball  engineers  would  always  make  time  to  answer  the  questions  of 
other  DINO  subsystems.  In  fact  many  of  these  ‘other’  subsystems  inherited 
advisors  as  a  result.  For  example,  the  thermal  team  was  in  need  of  advising  and 
so  inherited  the  mentorship  of  at  least  three  thermal  engineers  at  Ball  in  the 
areas  of  radiation  heat  transfer  analysis,  thermal  modeling,  and  MLI  blanket 
design.  A  similar  situation  occurred  with  the  DINO  wiring  harness  team.  Ball 
engineers  have  also  provided  consistent  advice  with  scheduling  and 
presentations. 

The  engineers  at  Ball  have  helped  guide  the  DINO  project  over  the  last  two 
years.  They  have  been  patient  and  understanding  with  the  small  mistakes 
sometimes  committed  by  undergraduate  students,  as  they  are  primarily 
interested  in  the  learning  experience  of  the  student,  but  have  also  helped  prevent 
large  mistakes  from  occurring.  The  hardware  and  monetary  donations  have 
assisted  DINO  significantly  but  has  been  nothing  in  comparison  with  the  time 
donation  that  engineers  have  given  to  the  students. 

3.2  Composite  Technologies  Development 

Composite  Technologies  Development,  CTD,  is  another  company  that  has 
invested  a  considerable  amount  of  resources  into  Space  Grant  in  the  form  of 
hardware,  funding,  and  mentorship.  CTD  is  an  emerging  company  that  is 
developing  around  composite  technologies.  Since  this  company  is  new,  it  is 
currently  working  to  obtain  flight  heritage.  For  this  reason,  CTD  has  selected 
DINO  as  an  inexpensive  way  to  demonstrate  the  performance  of  their  EMC 
hinges. 

CTD  engineers  designed  and  fabricated  the  hinges  while  Space  Grant  students 
conducted  several  functional  and  performance  tests  on  them  as  well  as  designed 
the  supporting  hardware  and  electrical  interfaces.  Space  Grant  students 
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determined  how  the  hinges  would  be  utilized  and  completed  the  final  assembly 
and  integration  of  them. 

The  challenge  for  Space  Grant  was  then  to  determine  the  best  way  to  utilize  this 
technology.  Originally  the  EMC  hinges  were  intended  to  deploy  two  aerofins 
from  the  side  of  the  spacecraft  in  order  to  help  with  attitude  control.  After  some 
analysis,  the  DINO  team  determined  that  the  aerofins  would  actually  lend 
minimal  benefit  with  significant  costs  in  mass.  During  the  Nanosat  III 
Subsystem  Design  Review  a  reviewer  suggested  putting  an  experiment  on  a 
deployable  panel  that  would  allow  the  spacecraft  to  measure  the  performance  of 
the  EMC  hinges.  After  considering  a  few  other  options,  this  became  the  ideal 
alternative  as  it  provides  Space  Grant  with  the  opportunity  to  produce  a  detailed 
analysis  of  the  hinge  performance  to  CTD.  In  order  to  do  so,  the  hinges  have 
been  mounted  so  as  to  deploy  a  panel  1 80°.  This  panel  has  a  rate  gyro  mounted 
to  it  that  will  provide  data  indicating  the  performance  of  the  hinges  that  deploy 
it. 

Most  of  the  work  with  CTD  occurred  during  the  summer  of  2004.  During  this 
time  the  DINO  team  worked  with  two  CTD  employees.  One  of  the  two 
employees  was  another  student  from  the  University  of  Colorado.  He  was 
working  at  CTD  on  a  summer  internship.  This  allowed  the  DINO  team  to  work 
with  another  student  in  a  different  setting. 

3.3  MicroSat 

MicroSat  Systems,  Inc.  has  contributed  to  DINO  by  donating  their  Foldable 
Integrated  Thin-Film  Stiffened  (FITS)  Solar  Arrays.  FITS  was  developed  so  as 
to  provide  maximum  surface  area  with  minimal  stowage  area.  FITS  can  be 
folded  and  stowed  up  against  a  structure.  By  using  their  FITS  Solar  Arrays, 
DINO  will  reduce  the  solar  array  mass  needed  by  50%. 

The  efficiency  of  thin-film  solar  arrays  is  less  than  the  efficiency  of  triple 
junction  body  mount  solar  arrays.  Currently  body-mount  solar  arrays  can 
provide  up  to  28%  efficiency  where  thin-film  arrays  can  only  provide  around 
8%  efficiency.  What  the  thin-film  arrays  lack  in  efficiency  they  make  up  for 
with  maximum  surface  area  and  minimum  mass.  FITS  will  provide  DINO  with 
90W  of  power  at  a  cost  in  mass  of  4kg.  DINO  is  not  only  demonstrating  this 
technology  but  is  also  depending  on  it  as  its  primary  source  for  power.  The 
flight-data  that  DINO  will  then  provide  MicroSat  will  characterize  the  FITS 
solar  array’s  performance  in  a  space  environment.  This  data  will  also  benefit 
AFRL’s  Roadrunner  project,  for  which  application  of  the  FITS  system  is 
intended. 

The  cells  were  entirely  designed  by  MicroSat  engineers,  while  Space  Grant 
students  designed  the  supporting  hardware  and  electrical  interfaces.  Space 
Grant  students  also  participated  in  the  final  assembly  of  the  FITS  engineering 
design  unit  as  well  as  its  final  integration  onto  DINO. 
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3.4  TiNi  &  Starsys 

The  hardware  donated  by  Ball,  CTD,  and  MicroSat  will  help  DINO  accomplish 
its  mission.  However,  these  generous  donations  created  new  design  challenges, 
as  each  component  requires  both  mechanical  and  electrical  interface  designs. 
Furthermore,  the  CTD  hinges  and  the  FITS  system  are  intended  for  deployment 
and  so  a  method  for  stowing  and  releasing  each  component  is  also  necessary. 
The  same  must  also  be  designed  for  the  antennas,  as  both  will  be  stowed 
initially  and  will  be  deployed  after  orbit  insertion.  Enough  actuators  must  be 
obtained  so  as  to  release  the  CTD  panel,  FITS  system,  and  each  antenna.  These 
actuators  must  not  only  be  appropriate  for  the  deployment  itself  but  also  must 
have  minimal  costs  to  mass,  power,  and  the  budget.  Most  low  mass,  low  power 
actuators  come  with  a  high  price  tag  so  Space  Grant  students  explored  several 
design  alternatives  and  approached  each  respective  company  with  donation 
requests.  Two  companies  responded:  TiNi  and  Starsys. 

TiNi  donated  two  FrangiBolt  actuators  to  DINO.  One  FrangiBolt  is  being  used 
to  restrain  the  CTD  deployment  panel  and  the  other  to  restrain  the  FITS  solar 
array.  The  FrangiBolt  is  a  bolt  that  is  designed  to  fracture.  This  bolt  is  placed 
inside  an  actuator  that  expands  upon  heating  until  the  bolt  snaps  in  half.  Both 
ends  of  the  fractured  bolt  need  to  be  contained  so  as  not  to  harm  other 
subsystems  inside  the  spacecraft  and  to  prevent  unnecessary  space  debris. 
Space  Grant  students  designed  support  hardware  in  order  to  satisfy  these 
requirements.  For  example,  each  FrangiBolt  is  housed  such  that  the  fractured 
bolts  are  permanently  contained  and  their  kinetic  energy  after  fracture  is 
absorbed  by  springs. 

Starsys  donated  a  third  actuator  for  the  antenna  deployment,  which  is  a  High 
Output  Paraffin,  HOP,  actuator.  This  device  is  a  titanium  can  containing 
paraffin  that  expands  causing  a  pin  to  be  pulled  slowly  and  smoothly.  In  order 
to  utilize  one  HOP  for  two  antennas,  Space  Grant  students  designed  supporting 
hardware.  Starsys  engineers  also  donated  time  for  reviewing  mechanical 
designs,  even  those  not  necessarily  related  to  the  HOP. 

3.5  Planetary  Systems  Corporation 

Planetary  Systems  Corporation  (PSC)  is  donating  the  Lightband  system  that  will 
be  used  to  actuate  the  boom  deployment.  This  will  be  used  to  deploy  the 
gravity  gradient  boom,  and  is  identical  to  the  system  being  used  for  the 
separation  of  DINO  from  the  Internal  Cargo  Unit  (ICU).  PSC  has  also  provided 
mentorship  at  the  Nanosat  III  reviews. 

3.6  Lockheed  Martin 

Lockheed  Martin  is  donating  solar  cells  for  the  body  mount  solar  arrays.  These 
solar  cells  were  designed  and  manufactured  in  house  at  Lockheed  Martin,  and 
are  the  innovative  design  remains  proprietary  information.  However,  Lockheed 
Martin  provides  advising  in  designing  support  hardware  and  will  leave  the  final 
integration  of  these  panels  to  Space  Grant  students. 
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4  K-12  Outreach 

K-12  outreach  is  very  important  to  the  DINO  project,  and  is  perhaps  one  of  the 
strongest  components  of  Space  Grant  as  a  whole.  An  individual  outreach  team  leader 
organizes  outreach  activities  that  are  to  be  facilitated  by  volunteers.  These  volunteers 
are  the  very  same  students  who  do  all  of  the  engineering  work  for  Space  Grant 
satellite  projects.  Over  the  last  two  years  DINO  student  volunteers  have  facilitated 
various  outreach  activities  that  have  involved  at  total  of  2,509  K-12  students.  This 
does  not  include  the  activities  run  by  students  involved  in  non-DINO  projects. 
Several  K-12  students  are  counted  more  than  once  because  some  have  participated  in 
multiple  activities  including  tours,  interactive  activities,  classroom  demonstrations, 
summer  workshops,  and  many  other  similar  endeavors. 

Space  Grant  is  not  only  interested  in  the  quantity  of  students  reached,  but  also  the 
quality  in  which  they  are  reached.  Space  Grant  targets  students  who  demonstrate  the 
greatest  need  for  exposure  to  science  and  engineering.  These  students  are  generally 
found  at  low-income  schools  attended  by  under-represented  minority  students  and/or 
financially  challenged  students.  Understandably,  these  schools  receive  priority 
although  there  are  countless  requests  for  outreach  activities  from  a  variety  of  schools. 
One  way  this  is  accomplished  is  through  the  recent  commitment  to  adopt  one 
elementary  school  per  semester  in  order  to  supplement  their  science  program  with  a 
four-week  after-school  activity  program  based  on  space  technologies.  This  has  now 
been  done  for  each  of  the  last  three  semesters. 

The  schools  that  were  adopted  so  far  have  been  part  of  the  Mathematics,  Engineering, 
and  Science  Achievement,  (MESA),  program,  http://vvwvv.cmesa.ore.  This  program 
is  intended  to  serve  K-12  schools  that  are  in  need  of  certain  educational  or  financial 
resources.  The  schools  that  have  been  adopted  thus  far  are  Spangler  Elementary  in 
Longmont,  Colorado  (Fall  -  2003),  Fitzmorris  Elementary  in  Aurora,  Colorado 
(Spring  -  2004),  and  Loma  Linda  Elementary  in  Longmont  Colorado  (Fall  -  2004). 
Each  of  these  programs  lasted  four  weeks,  and  was  developed  around  space 
technology,  engineering,  and  the  scientific  process  as  related  to  the  DINO  project. 

The  number  of  K-12  students  exposed  to  engineering  concepts  and  space  for  each 
month  over  the  last  two  years  can  be  seen  in  Figure  5  below. 


Page  12  of  14 


123  of  190 


DINO:  People  Involved 


DINO-PM-PRT-PEOPLE,  Rev.  A 


Outreach  By  Month  By  Year 


Months 


Figure  5:  Outreach  Numbers  by  Month 
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Appendix  A  -  List  of  Acronyms 


AIAA 


AFRL 


AFOSR 


CTD 


DINO 


EMC 


FITS 


GSFC 


HOP 


ICU 


MESA 


MLI 


PSC 


American  Institute  of  Aeronautics  and  Astronautics 


Air  Force  Research  Laborato 


Air  Force  Office  of  Scientific  Research 


Composite  Technologies  and  Development 


Deployment  and  Intelligent  Nanosat  Operations 


Elastic  Memory  Composite 


Foldable  Integrated  Thin-film  Stiffened 


Goddard  Space  Flight  Center 


High  Output  Paraffin 


Internal  Cargo  Unit 


Mathematics,  Engineering,  and  Science  Achievement 


Multi  Layer  Insulation 


Planetary  Systems  Corporation 
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1  Scope 

1 . 1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (ALAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1 .4  Document  Overview 

The  system  is  direct  energy  transfer  with  a  secondary  lithium-ion  battery  for  the 
main  satellite,  a  primary  28V  battery  for  the  deployable  devices,  a  main  solar 
array  the  Foldable  Integrated  Thin-film  Stiffened  (FITS)  and  body  mount  solar 
array.  The  body  mount  solar  array  will  have  a  start  up  12V  start  up  string  that 
will  go  power  up  the  satellite  upon  release  from  the  shuttle.  The  batteries  shall 
have  a  three-fault  tolerance  inhibit  system  to  prevent  the  satellite  from  turning 
on  prematurely.  The  expected  efficiency  of  the  entire  system  is  estimated  to  be 
80%.  The  system  will  provide  voltage  lines  of  5,  +12,  -12  and  28.  The  system 
will  use  up  to  120W  of  power  while  using  70W  during  regular  operations.  The 
system  is  designed  for  a  mission  life  of  one  year,  while  the  expected  duration  of 
the  mission  is  six  months.  The  satellite  must  remain  off  until  it  leaves  the 
Internal  Cargo  Unit  (ICU)  and  no  deployment  can  occur  until  after  the  satellite 
is  a  safe  distance  away  from  the  shuttle.  The  system’s  design  is  proprietary  by 
Ball  Aerospace  Technologies  Corporation  (BATC).  The  EPS  system  will  be 
located  on  the  zenith  plate  of  the  satellite.  A  power  control  card  will  provide 
functions  of  charge  control,  power  conditioning,  conversion  and  distribution. 
The  EPS  system  will  use  a  star  node  configuration-grounding  scheme  with  the 
center  node  being  the  EPS  system.  The  EPS  system  will  take  commands  from 
C&DH  through  an  RS-422  serial  line.  Health  and  status  will  be  sent  to  C&DH 
when  requested.  EPS  will  also  receive  a  status  signal  from  C&DH  to  determine 
if  it  is  operational.  When  the  signal  is  not  received  within  a  10-minute  time 
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span  power  to  C&DH  will  be  turned  off  and  reestablished  two  seconds  after 
power  us  cut.  The  system  shall  have  four  modes  of  operations:  normal  daytime 
operations,  normal  nighttime  operations,  deployment  mode  and  safe  mode. 


1.5  Referenced  Documents 

None 

2  Power  Generation 

The  satellite  will  be  power  by  the  FITS  solar  array  provided  by  Microsat  Systems  inc. 
The  FITS  will  provide  a  minimum  of  90W  during  end  of  life  with  an  expected  value 
of  19V.  The  FITS  are  8%  efficient  and  is  expected  to  increase  in  efficiency  when  the 
satellite  is  delivered  for  flight.  The  FITS  is  series  of  Gallium-copper  cells  connected 
together  to  form  strings.  The  FITS  will  be  folded  up  and  unable  to  provide  power  to 
the  satellite  until  it  is  deployed  by  a  frangibolt.  The  deployment  of  the  FITS  will  be 
completed  within  a  30  second  time  frame.  The  FITS  is  a  single  solar  array  with  a 
minimum  of  4  strings  going  into  the  EPS  card.  The  FITS  shall  last  for  the  entire 
mission  duration  of  6  months  and  be  designed  to  last  for  the  mission  goal  of  1  year. 
One  of  the  solar  array  strings  shall  be  capable  of  being  pulse  width  modulated  to  a 
increase  the  systems  efficiency.  By  pulse  modulating  the  string  it  will  allow  the 
system  to  receive  the  needed  power  and  let  the  excess  power  dissipate  into  heat  on  the 
solar  array. 

The  body  mount  solar  array  shall  be  capable  of  supporting  the  satellite  should  the 
FITS  be  unable  to  provide  the  power  needed.  Due  to  the  constraints  of  surface  area 
and  cell  efficiency  the  maximum  power  the  body  mount  will  produce  is  25W.  The 
body  mount  array  shall  be  place  upon  four  of  the  side  panels.  The  body  mount  will 
contain  a  string  specification  to  startup  the  satellite.  The  startup  string  will  have  a 
voltage  of  12V  and  will  be  located  on  2  of  the  side  panels.  The  body  mount  array 
shall  be  inhibited  by  the  EPS  card  with  a  MOSFET  switch  while  the  startup  string 
shall  be  inhibited  by  the  separation  switches  of  the  lightband. 


3  Batteries 

3.1  Power  Storage 

The  system  will  store  power  in  lithium-ion  polymer  cells  with  a  capacity  of  4Ahr  and 
nominal  voltage  3.7V  and  a  maximum  voltage  of  4.1.  The  main  battery  will  be 
composed  of  4  lithium-ion  cells  connected  in  series  and  have  a  nominal  voltage  of 
14.8V.  The  lithium  cells  will  be  the  main  battery  for  the  satellite.  The  battery  is 
sized  to  last  three  eclipse  periods  before  charging  is  needed  and  has  an  expected  life 
of  2,000  cycles  of  charging  and  discharging.  The  battery  shall  be  discharge  to  75%  of 
its  maximum  capacity  at  the  end  of  the  three  eclipse  periods.  The  battery  shall  not  be 
discharged  below  60%  capacity.  The  battery  will  lose  all  capacity  once  it  is 
discharged  completely  and  discharging  below  60%  will  cause  major  capacity  loss. 
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The  battery  will  have  a  current  monitor,  a  voltage  monitor,  voltage  monitors  for  each 
cell  and  2  sets  of  thermal  couple:  1  set  for  flight  and  the  other  for  ground  support 
equipment.  The  charge  plan  for  the  battery  is  to  perform  sub-capacity  charging  to 
95%  for  the  default  of  the  mission,  occasionally  charge  the  battery  to  100%  to 
recharge  the  battery  to  full  capacity  and  charge  the  battery  to  103%  to  recover 
capacity  of  battery  near  the  end  of  the  mission.  Ball  will  certify  the  battery  in  their 
facilities  with  the  assistance  of  CSGC  students.  The  inhibit  scheme  will  require  1 
inhibit  on  the  negative  leg  and  3  on  the  positive  leg  to  satisfy  the  three  fault  tolerance 
requirement. 


3.2  Primary  9 V  Deployment  Battery 

Six  9V  alkaline  cells  will  power  the  deployable  devices.  The  battery  cells  will  be 
configured  as  shown  in  figure  1.  Each  cell  has  a  mass  of  50  grams  and  the  entire 
assembly  will  have  a  total  mass  of  300  grams.  The  battery  will  be  flown  fully 
charged  and  is  expected  to  have  1  inhibit  on  the  negative  leg  and  3  on  the  positive  leg. 
This  is  done  to  comply  with  NASA  safety  standards  and  prevent  any  early 
deployments  of  the  devices.  The  battery  will  be  independent  from  the  rest  of  the 
satellite  and  is  meant  for  a  one-time  use  so  it  will  not  be  charged.  This  battery  will  be 
used  only  to  trigger  the  HOPS,  lightband  system,  frangibolts  and  the  memory  hinges. 
The  battery  shall  be  capable  of  supplying  1.4A  at  anytime  during  the  deployment. 
The  devices  shall  be  deployment  one  at  a  time  and  all  deployments  are  to  be 
completed  during  the  first  week  of  the  mission.  These  batteries  shall  have  the  air 
vents  pointed  up  to  satisfy  NASA  safety  requirements.  The  battery  shall  have  a 
voltage  monitor,  a  current  monitor  and  one  thermal  couple  placed  in  the  center  of  the 
battery  configuration. 


- 9  V  - 9  v 


Figure  1 
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4  Mission 

The  system  must  provide  power  to  the  satellite  for  the  mission  duration  of  3,500 
cycles  (approximately  six  months)  and  power  for  the  mission  goal  of  7,000  cycles. 
The  satellite  shall  be  in  an  ISS  orbit  and  must  compile  with  shuttle  safety  standards. 
The  primary  battery  must  power  the  satellite  for  three  eclipse  times  of  35  minutes 
each.  The  satellite  will  be  in  the  sunlight  for  and  average  time  per  orbit  55  minutes. 
The  power  system  will  test  and  exhibit  the  technologies  of  MicroSat  Inc.,  BATC, 
Broad  Reach  Engineering  and  Spaceworks  Corporation. 


5  EPS  Controls 

The  system  will  take  samples  of  all  of  the  monitors  and  sends  the  information  when 
requested  by  C&DH.  The  system  shall  depend  upon  the  C&DH  to  give  instructions 
on  what  tasks  to  perform.  The  EPS  card  will  be  connected  to  C&DH  through  a  RS- 
422  line.  The  EPS  shall  have  total  control  over  the  solar  arrays,  the  charge  control 
and  the  Power  on  Reset  while  C&DH  will  have  control  over  the  power  switches  and 
monitor  data.  The  EPS  shall  monitor  a  signal  from  C&DH  to  determine  its  current 
status.  If  the  signal  is  not  received  in  a  time  span  of  10  minutes  the  EPS  system  shall 
open  the  switch  supplying  power  to  the  flight  computer  to  cause  a  reset.  The  power 
shall  be  turned  off  for  two  seconds  and  power  will  be  restored.  EPS  will  go  into  a 
default  mode  until  the  C&DH  instructs  the  system  otherwise. 

All  switches  on  the  system  are  controlled  by  a  high  or  low  signal.  A  high  signal  of 
5V  will  close  a  switch  and  complete  the  circuit.  A  low  signal  of  0V  will  open  the 
switch  causing  a  break  in  the  circuit.  All  switches  except  for  the  C&DH  switch  will 
remain  open  until  it  is  instructed  to  close.  The  C&DH  switch  will  remain  closed  until 
instructed  to  open.  This  is  done  to  ensure  the  system  will  turn  on  once  the  satellite 
leaves  the  ICU  and  it  makes  the  Power  On  Reset  (POR)  easier  to  design.  The  inhibits 
used  are  latching  relays  that  are  open  until  instructed  to  close  and  once  instructed  to 
close  the  latching  relays  remain  closed. 
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6  EPS  Control  Card 

The  EPS  control  card  shall  use  a  PIC  microcontroller  to  control  the  functions  on  the 
card.  The  microcontroller  will  communicate  with  C&DH  through  an  RS-422  serial 
line.  EPS  will  send  health  and  status  of  the  card  to  C&DH  when  requested.  EPS 
shall  control  a  watchdog  timer  to  turn  off  the  power  to  C&DH  when  a  monitored 
heartbeat  signal  is  not  receive  for  a  time  span  of  10  minutes.  The  heartbeat  signal 
will  be  sent  over  the  RS-422  serial  line  as  well  as  a  dedicated  I/O  line.  When  the 
signal  is  not  receive  EPS  shall  cut  power  to  C&DH  for  two  seconds  and  then  restore 
power.  For  the  microcontroller  to  handle  all  of  the  I/O  signals  on  the  EPS  card 
expander  chips  will  be  used  to  increase  the  amount  of  I/O  the  PIC  can  process.  The 
EPS  card  shall  control  all  functions  of  the  solar  array,  the  FITS,  the  PWM  and  the 
charge  control. 

The  MPU  used  for  the  EPS  card  will  be  a  PIC16C77.  The  MPU  uses  RISK 
architecture  and  35  word  instructions.  It  is  a  8-bit  microcontroller  with  a  12-bit  A/D 
and  three  timers.  The  capture  feature  is  16-bit  with  a  maximum  resolution  of  12.5  ns. 
The  compare  feature  is  16-bit  with  a  resolution  200  ns.  The  MPU  also  provides 
support  for  high/low  speeds  and  a  9-bit  address  mode  supporting  Universal 
Synchronous  Asynchronous  Receiver  Transmitter. 

7  Charge  Control 

The  control  card  will  have  three  settings  for  charging  the  main  battery.  The  sub¬ 
capacity  charge  will  charge  the  battery  at  1.7A  until  the  voltage  reaches  95%  of  it 
capacity.  This  is  done  to  increase  the  power  efficiency  in  the  system  and  prevent  the 
cells  from  over  charging.  The  full-capacity  charging  will  charge  the  battery  stack 
until  the  battery  is  fully  charged  once  again.  This  is  done  to  maintain  the  capacitance 
and  to  help  the  battery  cells  maintain  similar  characteristics.  The  overcharge  will 
charge  the  battery  to  103%  to  extend  the  life  of  the  battery  when  the  cells  start  to 
degrade.  To  ensure  the  battery  is  charge  to  the  appropriate  level  a  comparator  will  be 
used  to  control  the  charging.  Once  the  voltage  level  exceeds  the  upper  limit  on  the 
comparator  charging  will  be  turned  off.  The  comparison  voltage  will  be  altered 
according  to  the  desired  charge  mode. 


8  Pulse  Width  Modulator 

The  pulse  width  modulator  (PWM)  is  a  MOSFET  switch  that  will  be  toggled  to 
produce  a  desired  average  current.  Using  a  PWM  increases  the  efficiency  of  the 
power  system  by  supplying  the  system  with  the  amount  of  power  required  and 
leaving  the  excess  power  to  be  dissipated  into  heat  on  the  solar  array.  The  PWM 
open  switches  until  power  draw  is  constant  then  toggle  switches  until  a  stable  power 
use  is  established.  The  PWM  will  adjust  itself  to  supply  the  satellite  with  enough 
power.  The  PWM  will  be  controlled  only  by  the  EPS  microcontroller. 
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9  Power  Lines 

The  system  will  have  voltage  lines  of  5,  +12,  -12  and  28.  The  power  supplies  for  the 
12V  line  shall  be  rated  to  30W  and  the  5V  line  shall  be  rated  to  25 W.  A  battery  rated 
to  2.1  Ahr  at  27V  will  source  the  28V  power  lines. 


10  Grounding 

DINO  shall  use  a  star  pattern  for  it  grounding  scheme.  The  center  node  of  the  star 
pattern  shall  be  the  EPS  card  and  all  return  paths  will  go  to  the  EPS  card.  The  EPS 
card  shall  have  a  3  Mohm  resistance  between  itself  and  the  structure. 


1 1  Safety 

NASA’s  safety  documents  state  that  all  power  sources  must  have  at  least  3  inhibits  to 
prevent  the  sources  from  being  turned  on  premature.  One  inhibit  must  be  on  the 
negative  leg.  The  batteries  DINO  intends  to  use  will  be  lithium-ion  polymer 
chemistry,  it  will  require  4  inhibits.  The  main  and  secondary  battery  will  both  be 
fully  charged  and  requires  higher  safety  precautions.  The  solar  arrays  will  only  need 
1  inhibit  because  the  satellite  will  be  in  an  ICU,  there  will  be  no  light  for  the  solar 
array  to  power  the  satellite  and  that  can  be  counted  as  an  inhibit.  More  details  on  the 
how  the  lithium-ion  batteries  will  pass  safety  concerns  will  be  provided  by  Ball 
Aerospace.  The  28V  battery  will  also  use  4  inhibits  as  well  due  to  the  fact  it  will  be 
charged  during  the  launch.  The  28V  battery  will  be  in  an  enclosed  box  and  contain  a 
venting  hole  to  let  out  any  gases  that  will  cause  hazards  to  the  system.  Inhibits  for  the 
solar  array  and  batteries  will  trigger  once  the  micro  switches  close,  that  will  give 
power  to  the  essential  systems.  The  other  inhibits  will  be  controlled  by  the  EPS  card 
by  commands  from  C&DH. 


12  Inhibits 

The  EPS  card  shall  use  latching  relays  as  the  inhibits  for  the  batteries  and  MOSFET 
switches  for  the  loads  of  the  satellite.  The  latching  relays  are  used  for  the  battery 
because  they  can  handle  large  amounts  of  current  and  remain  in  their  current  position 
until  instructed  to  change.  Once  the  latching  relays  are  closed  they  will  remain  closed 
to  minimize  risk  should  the  EPS  card  come  across  a  failure.  MOSFET  switches  are 
used  for  the  loads  due  to  their  simplicity  and  the  switches  default  to  an  open  state. 
All  switches  and  inhibits  are  controlled  by  the  EPS  micro-controller,  the  switches  and 
relays  response  to  a  high  low  signal  of  5  and  0V 
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13  Power  Structure 

The  power  structure  will  be  fabricated  by  SpaceWorks  and  delivered  to  CSGC. 
CSGC  will  determine  the  dimensions  and  basic  outline  of  the  structure.  SpaceWorks 
shall  determine  the  power  structures  composition,  properties,  fabrication  and  tooling. 
The  power  panel  will  be  the  entire  zenith  panel  of  the  satellite.  The  power  panel  shall 
integrate  itself  with  the  structure  and  provide  mounting  for  the  boom  and  the  rest  of 
the  satellite.  The  structure  will  also  house  the  battery  assembly  and  dissipate  the  heat 
generated  by  the  power  system.  The  structure  shall  be  design  to  account  for  the  light 
band  separation  and  the  deployment  of  the  boom. 

The  structure  shall  be  composed  of  a  graphite  fiber  reinforced  epoxy  resin  and  space 
qualified  epoxy.  The  main  panel  shall  consist  of  MS  ID  and  MS4A.  The  power  panel 
will  have  a  radius  of  39.77cm,  a  thickness  of  1.91  cm  and  have  a  mass  of 
approximately  2.10  kg.  The  structure  shall  have  an  aluminum  interface  with  the 
satellite  side  panels  for  integration.  The  structure  shall  be  conductive  with  the  rest  of 
the  satellite. 
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Appendix  A  -  List  of  Acronyms 

ADCS-  Attitude  Determination  and  Control  System 
BATC  -  Ball  Aerospace  Technologies  Corp. 

C&DH  -Command  and  Data  Handling 

COMM-  Communitcations 

CSGC  -  Colorado  Space  Grant  Consortium 

EPS  -  Electrical  Power  System 

FITS  -  Foldable  Integrated  Thin-film  Solar 

ICU  -  Integrated  Cargo  Unit 

PWR-  Power 
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DINO  Science  Subsystem  Stereoscopic  Imaging: 
Gradient-Based  Stereoscopic  Algorithm 
Pascal  Getreuer 


A  major  goal  in  the  DINO  Satellite  project  is  to  implement  stereoscopic  imaging  based  on  pho¬ 
tographs  from  the  on  board  digital  cameras.  In  order  to  reduce  the  amount  of  data  transmitted  to 
ground,  most  of  the  stereoscopic  processing  is  to  be  done  on  the  satellite  itself.  In  previous  reports, 
we  developed  the  pre-processing  necessary  to  compensate  for  camera  orientations  and  nonlinear 
lens  distortions.  This  report  covers  specifically  the  theory  of  the  stereoscopic  algorithm,  basic 
implementation,  optimizations,  and  demonstration  of  the  algorithm’s  results  on  real  photograph. 

The  goal  in  stereoscopic  imaging  is  to  find  the  local  horizontal  and  vertical  translations  between 
two  images.  Stereoscopic  imaging  is  one  of  the  earliest  and  most  actively  investigated  topics  in 
computer  vision;  this  is  a  non-trivial  problem.  A  great  pitfall  in  attempting  stereoscopic  imaging 
is  the  assumption  that  matching  individual  pixels  between  the  two  images  yields  the  translation. 
The  amount  of  local  information  at  each  point  is  insufficient  to  solve  the  matching  problem;  if 
the  similarity  were  to  be  maximized  for  each  point  in  isolation,  the  result  would  be  noisy  and 
inconsistent.  Instead,  a  multi-scale  approach  is  necessary.  Another  difficulty  is  that  directly 
comparing  pixel  intensities  is  unstable.  In  practice,  individual  cameras  have  differing  additive  and 
multiplicative  intensity  factors,  thus  comparisons  must  be  made  in  another  way. 

Implementation  Concerns 

As  most  of  the  processing  is  to  be  done  on  the  satellite,  in  addition  to  the  algorithm’s  reliabil¬ 
ity,  some  concerns  are  algorithmic  complexity,  workspace  memory,  code  memory,  floating-point 
operations,  and  MATLAB  to  C++  translation.  In  addition,  the  amount  of  data  transmitted  to 
the  ground  is  a  significant  concern.  While  these  issues  seem  to  be  more  of  the  software  group’s 
interest,  the  computational  intensity  of  this  algorithm  requires  collaboration  and  careful  thought 
for  effective  realization  on  DINO’s  computer  system.  Approaches  to  some  of  these  implementation 
challenges  will  be  proposed. 


Gradient-Based  Stereoscopic  Imaging 

The  stereoscopic  imaging  algorithm  discussed  in  this  report  is  based  on  Scharstein’s  [3]  gradient- 
based  approach.  The  basic  procedure  is 

•  Pre-processing  filtering 

•  Approximating  image  gradients 

•  Multi-scale  aggregation  and  matching 

•  Post-processing  filtering 

In  the  (optional)  pre-processing  step,  bandpass  filtering  and  edge  enhancement  improve  the  image 
clarity  in  the  matching  steps.  Image  gradients  are  approximated  for  use  in  the  matching  criterion. 
The  actual  matching  is  done  by  finding  the  best  match  measure  for  every  translation  for  every 
pixel  for  multiple  scales  through  aggregation  of  a  similarity  measure  over  local  neighborhoods.  A 
rough  translation  map  results  from  this  main  procedure.  In  post-processing,  occlusion  boundary 
effects  are  reduced  with  edge  enhancement  and  constant  depth  extrapolation  fills  in  unmatched 
regions. 
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Measures  for  Matches 

Stereoscopic  imaging  is  often  based  on  two  separate  measures  for  matching  at  a  point,  a  “confi¬ 
dence”  measure  and  a  “difference”  measure.  Given  the  intensity  gradients  gx  and  <?•>, 

Kim  +  ii&iy 

measures  the  confidence  of  a  match  while 


llih  -52II2 

measures  the  difference.  While  many  algorithms  consider  the  two  measures  separately,  Scharstein’s 
particular  algorithm  combines  them  into  one  measure  of  the  “evidence”  of  a  local  match 

E  =  \  (llflill  +  ll&ll)  —  —  y2||  (1) 

where  q  is  a  parameter  to  tune  the  selectivity  of  the  matching.  According  to  Scharstein,  a  =  1  is 
a  good  choice  and  its  exact  value  does  not  significantly  change  the  results. 


Approximating  Gradients 

The  evidence  measure  (1)  requires  the  intensity  gradients  of  both  images.  Let  I\  (x,  y)  be  the 
intensity  of  the  first  image  at  pixel  (2,  y)  and  similarly  let  h{x,  y)  be  the  intensity  for  the  second 
image.  The  gradients  can  be  approximated  with  the  Sobel  filter,  which  is  composed  of  a  derivative 
filter  along  one  direction  and  a  prefilter  in  the  orthogonal  direction.  This  construction  provides 
smoothness  over  simple  differencing. 


£li{x,  y)  k  Ii(x,  y)  * 


'  -1 

0 

1  ‘ 

1  2  1 

-2 

0 

2 

y)  «  7j(x,  y)  * 

0  0  0 

-1 

0 

1 

-1  -2  -1 

(2) 


An  alternative  are  Simoncelli’s  filters,  designed  such  that  the  derivative  filter  is  a  good  approxi¬ 
mation  of  the  derivative  of  the  prefilter.  The  3x3  horizontal  filter  is 


0.2242 

0.5516 

0.2242 


x  [  -0.4553  0  0.4553  ] 


and  the  5x5 


0.0357 

0.2489 

0.4308 

0.2489 

0.0357 


x  [  0.1077  -0.2827  0  0.2827  0.1077  ] 


For  both  the  Sobel  and  Simoncelli  filters,  Scharstein  recommends  also  applying  a  light  smoothing 
filter  such  as  a  Gaussian  filter  with  a  —  0.5  pixels  to  the  gradient  approximation  to  attenuate 
quantization  errors. 


Aggregation 

Combining  the  evidence  measure  (1)  and  gradient  approximation  (2),  the  evidence  for  a  local 
match  at  point  (x,  y)  for  translation  S  is 

Ei(x,y)  =  |  (| | V/x (x,  y)\\  +  ||VJ2(x  +  Sx,  y  +  <5y)||) 

-q  HV/^x,  y)  -  V/2(x  +  8x,y  +  <5y)||  (3) 
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As  stated  earlier,  the  goal  is  not  to  match  isolated  points  but  to  maximize  the  similarity  between 
neighborhoods.  Thus,  we  must  aggregate  the  evidence  measure  Es(x,  y)  in  a  local  neighborhood. 
One  possibility  is  a  Gaussian  filter  with  standard  deviation  a, 

GaussianFilter(Es)(x,  y)  =  Es(x,  y)  *  (4) 

With  the  smoothed  evidence  map,  matching  is  done  at  multiple  scales.  The  best  S  in  some  range 
is  found  for  each  pixel  at  varying  neighborhood  sizes.  This  approach  suppresses  false  matches  and 
fills  in  less  textured  areas  at  the  larger  scales,  and  can  identify  sharper  features  at  finer  scales.  For 
the  512  x  384  pixel  test  images,  a  scale  at  a  =  2.2  and  at  0  =  7  were  used. 

Aggregation  is  based  on  the  assumption  that  the  translation  S  is  almost  the  same  for  neighboring 
pixels,  observing  that  typical  natural  scenes  are  composed  of  solid,  continuous  surfaces.  Discon¬ 
tinuities  at  object  edges  and  occlusion  boundaries  disrupt  this  assumption  and  result  in  bleeding 
and  blurring  artifacts  in  the  translation  map.  Occlusion  boundaries  are  the  biggest  problem  in 
aggregation  stereo  methods,  however,  the  effects  can  be  cleaned  up  somewhat  in  post-processing. 

Experimental  Results 

The  aggregation  step  is  the  bulk  of  the  algorithm’s  work,  resulting  with  a  rough  translation  map 
of  size  Nx  x  Ny.  Points  where  the  evidence  measure  (1)  is  negative  for  all  attempted  translation 
are  left  “unmatched”  in  the  translation  map.  Here  are  some  raw  translation  maps  produced  by  my 
MATLAB  implementation  of  the  stereoscopic  algorithm  on  real  photographs  (scaled  to  512  x  384 
pixels).  In  the  images  below,  lighter  shades  in  the  translation  maps  are  closer,  darker  are  further, 
and  black  marks  unmatched  regions.  The  evidence  at  each  point  for  the  best  translation  is  shown 
with  lighter  shades  indicating  stronger  matches.  Notice  that  more  textured  regions  correspond  to 
better  evidence  measures. 


Image  1  Image  2 
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Image  1  Image  2 


Translation  Map  Compression 

Due  to  the  limited  transmission  rate,  the  data  sent  to  the  ground  must  be  under  20  kilobytes 
(20480  bytes).  For  a  translation  map  of  size  Nx  x  Ny  using  one  byte  per  pixel,  the  largest  square 
map  possible  is  only  143  x  143.  For  better  resolution,  it  is  necessary  to  compress  the  translation 
map. 

One  promising  method  for  lossy  and  lossless  image  compression  are  integer-to-integer  wavelet 
transforms.  Wavelet  transforms  typically  outperform  JPEG  DCT-based  compression.  Further¬ 
more,  JPEG  suffers  from  blocking  artifacts,  and  as  post-processing  includes  edge-enhancement, 
this  is  not  acceptable.  Integer-to-integer  wavelet  transforms  can  be  performed  in  place  using  only 
integer  operations;  they  are  computationally  efficient. 

Wavelets  factored  into  a  Lifting  Scheme  are  performed  through  a  sequence  of  “predict"  and  “up¬ 
date”  stages. 


x?  a>’ 


The  input  signal  x  is  first  split  into  the  even  xe  and  odd  xa  components.  Then  the  first  predict 
stage  is  applied  to  x0 , 

x'a  =  x0  +  xe  *  Pi 

where  P\  is  a  FIR  (convolution)  filter.  Next,  the  first  update  stage  is  applied  to  xe, 

x'e  =  xe  +  x'a  *  Ui 
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The  process  continues  with  a  second  update  stage, 

<  =  x'o+x'e*P2 

In  general,  the  lifting  can  continue  further  with  alternating  predict  and  update  stages.  Once 
the  signal  passes  through  all  the  stages,  xe  are  the  approximation  coefficients  and  xQ  are  the 
detail  coefficients.  The  approximation  coefficients  are  often  scaled  larger  to  weight  their  greater 
significance  relative  to  the  detail  coefficients.  The  inverse  transform  simply  subtracts  the  stages  in 
reverse, 


Because  only  one  stage  is  changed  at  a  time,  the  Lifting  Scheme  transform  is  always  reversible 
-  even  with  nonlinear  stage  filters.  In  particular,  to  perform  the  transform  with  only  integer 
operations,  integer-to-integer  wavelet  transforms  round  the  filtered  sequences  before  adding.  For 
an  integer  input  signal,  the  inverse  yields  perfect  reconstruction. 

Adams  and  Kossentini  [1]  use  a  brute-force  search  for  Lifting  Scheme  biorthogonal  wavelets  with 
all  dyadic  rational  coefficients  with  good  wavelet  properties.  The  wavelets  provide  strong  frequency 
localization  and  vanishing  moments  optimized  for  the  purpose  of  image  compression.  The  results 
from  their  search  include 


5/11 


6/14 

13/7 


'  Pi(*)  =  i(-z-  1) 

-  U1(z)  =  \(l  +  z~1) 

.  P2(z)  =  ±{Z2  -Z-l  +  Z-1) 

'  pi(z)  =  -1 

<  Ul{z)  =  ^(-2  +  16  +  Z_1) 

,  P2 (z)  =  £( Z 2  -  Z  +  Z~l  -  Z~2) 

j  Pi(z)  =  i(3 z2  -  19 z  -  19  +  32-1) 
|  Ui(z)  =  z  +  5  +  5 z_1  -  z~ 2) 


5/11  and  6/14  are  designed  such  that  they  can  be  performed  with  only  additions  and  bit  shifts. 
13/7  requires  integer  multiplications  but  has  slightly  stronger  compression  capabilities.  Adams 
and  Kossentini  do  not  define  how  to  scale  the  approximation  coefficients.  My  own  experimentation 
found  \/2  to  be  a  good  scaling  factor  for  these  wavelets,  however,  for  computational  efficiency,  2 
works  reasonably  well. 


Wavelet-based  compression  will  be  performed  on  the  translation  map  in  the  following  steps 

•  Perform  an  integer-to-integer  wavelet  transform  on  the  translation  map  to  some  level  of 
decomposition  (third  to  sixth  level) 

•  Threshold  all  wavelet  coefficients  below  some  magnitude  to  zero 

•  Apply  run-length  encoding  to  the  resulting  coefficients  to  compress  long  sequences  of  zeros 
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With  this  approach,  it  is  computationally  efficient  and  algorithmically  simple  to  compress  trans¬ 
lation  maps.  With  wavelet  image  compression,  it  is  realistic  to  yield  20:1  compression  ratios  with 
nearly  imperceptible  loss  in  quality.  For  smoother  input  images,  this  ratio  can  be  higher  yet.  In 
order  to  meet  the  20  kilobyte  limit,  a  1024  x  768  pixel  translation  map  would  need  at  least  39:1 
compression.  Below  is  a  demonstration  of  this  with  the  translation  map  found  earlier  at  various 
thresholding  ratios  using  the  5/11  wavelet.  The  actual  data  compression  ratios  depend  on  the 
particular  run-length  encoding  method  used. 


Original  40:1  PSNR  =  23.88  dB 


Even  at  extreme  thresholding  ratios,  the  dominant  low-scale  information  is  retained.  Notice  that 
the  image  degrades  smoothly  -  no  blocking  artifacts.  Wavelet  compression  performs  well  for  high 
quality/low  compression  ratios  as  well  as  for  low  quality/high  compression  ratios. 

Improvements 

The  difficulty  in  aggregation  stereoscopic  methods  using  the  right  neighborhood  size.  Using  too  big 
of  a  neighborhood  more  frequently  violates  the  smooth  translation  assumption  while  too  small  of  a 
neighborhood  is  more  likely  to  falsely  match  and  produce  inconsistent  translations.  One  approach 
is  to  first  perform  aggregation  as  described,  and  then  to  use  the  edges  in  the  resulting  translation 
map  to  make  a  second  pass  of  aggregation  with  neighborhoods  fitting  within  these  edges.  Diffusion 
stereoscopic  methods  iterate  aggregation  in  a  similar  manner.  Such  methods  are  yet  more  intense 
than  simple  aggregation,  but  they  significantly  improve  effects  at  edges  and  occlusion  boundaries. 

A  computationally  cheaper  (but  lower  quality)  alternative  to  diffusion  methods  is  to  filter  the 
aggregation  results  as  post-processing.  Because  these  operation  can  be  done  without  the  original 
photographs,  the  DINO  Satellite  can  transmit  the  raw  translation  map  to  the  ground  for  further 
manipulation.  For  refining  object  edges,  instead  of  Scharstein’s  method  of  Canny  edge  detection 
and  then  thresholding,  an  alternative  is  the  nonlinear  bilateral  filter  [2],  As  both  diffusion  and 
post-processing  are  fine-tuning  done  on  the  aggregation  results,  these  topics  will  be  discussed  in 
further  detail  later  once  the  current  aggregation-only  implementation  is  established. 
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Appendix  A  —  Approximations 

With  the  high  computational  intensity  of  the  stereoscopic  algorithm,  Scharstein  includes  methods 
to  speed  up  some  of  the  more  costly  operations.  As  the  aggregation  step  of  the  algorithm  costs  most 
of  the  processing  time,  the  focus  is  on  speeding  up  the  particular  operations  involved.  Significant 
optimizations  can  be  made  by  approximating  the  L2  norm  with  an  “octagon”  norm  and  applying 
another  trick  to  approximate  Gaussian  filtering. 

Approximating  the  L2  Norm 

In  evaluating  the  evidence  measure  (1),  the  stereoscopic  algorithm  involves  calculating  many  vector 
L2  norms. 

Ml,  =  (£*?) 1/2 

Depending  on  the  hardware,  the  square  root  can  be  very  costly.  Scharstein  proposes  a  clever 
combination  of  the  L\  and  Lx  norms  to  approximate  the  L2  norm.  These  two  are  easier  to 
compute  than  the  L2  norm. 


IMIi  =  £l**l  IMIoo  =  maxN 

l 

Geometrically,  the  set  of  all  x  6  R2  such  that  ||x||2  =  1 
lie  on  the  unit  circle.  In  the  L\  norm,  vectors  such  that 
IMIi  =  1  lie  in  a  diamond  shape  within  the  unit  circle. 
The  vectors  such  that  HxH^  =  1  lie  in  a  square  containing 
the  unit  circle. 


The  approximation  combines  the  L\  and  norms  into  an  octagon  norm.  | |m| |oci  =  1  is  an 
octagon  fitting  closely  to  the  unit  circle. 

IML*  =  [(%/2  - 1)  IMIi  +  (2  -  n/2)  IMIoo] 

«  0.397811x11! +0.5626  llxll^ 

For  its  simplicity,  this  low-cost  approximation  is  very  close  -  within  4%  of  the  L2  norm  everywhere. 


Approximating  Gaussian  Filter  Convolution 

Scharstein  notes  that  it  is  much  faster  to  use  “box  filters”  instead  of  a  Gaussian  filter  in  the 
aggregation  step.  Applying  the  “box  filter”  of  size  (2  Bx  +  1)  x  (2 By  +  1): 


BoxFilter(E$)(x,  y)  =  Es(x,  y )  * 


+i) 


1  1 

1  1 
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i=l 


(5) 
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The  above  computation  has  nearly  the  same  operations  count  for  any  box  size  Bxx  By.  While  the 
Gaussian  convolution  requires  0(NxNyw2)  for  a  filter  size  w  x  w,  the  computational  complexity 
of  the  box  filter  as  in  (5)  does  not  depend  on  the  filter  size.  Especially  for  wide  neighborhoods, 
it  is  much  faster  to  use  box  filters.  The  Gaussian  filter  can  be  efficiently  approximated  by  three 
or  four  box  filters  in  sequence  [4].  Potentially,  other  smoothing  filters  could  be  approximated 
as  well.  Scharstein  observes  that  a  more  localized  cone-shaped  weighting  has  advantages  over 
Gaussian  filter;  it  may  be  useful  to  investigate  various  filter  shapes  and  their  efficient  box  filter 
approximation. 


Appendix  B  -  MATLAB  Code 

GradientStereo.m 

function  [T.EMax]  =  GradientStereo (Imgl ,Img2 .Translation) 
'/.GRADIENTSTEREO  Gradient-Based  Stereoscopic  Vision 
'/,  T  =  GradientStereo  (Imgl,  Img2, Translation) 

7. 

*/,  Find  the  translation  map  T  from  Imgl  and  Img2.  Translation 
'/,  specifies  the  set  of  horizontal  displacements  to  test. 

7. 

I  Implementation  by  Pascal  Getreuer  March  2004 
N  =  size(Imgl); 

if  length (N)  "=  2  I  ndims(Img2)  ~=  2 

error (’Only  two-dimensional  images  allowed.’); 

end 

if  N  ~=  size(Img2) 

error(’ Images  must  be  the  same  size.’); 

end 

l  approximate  image  gradients 
Kernel  =  [-1 , 0 , 1 ; -2 , 0 , 2 ; -1 , 0 , 1] ; 

’/.Kernel  =  [0.2242;0. 5516;0. 2242] * [-0. 4553,0,0. 4553]  ; 

Kernel  =  conv2(Kernel,GaussianFilter(0.5,3,3)) ; 

GradlX  =  conv2(Imgl, Kernel, ’same’) ; 

GradlY  =  conv2(Imgl, Kernel’ , ’same’) ; 

Grad2X  =  conv2(Img2, Kernel, ’same ’ ) ; 

Grad2Y  =  conv2(Img2, Kernel’ , ’same’) ; 

GradMagl  =  sqrt (GradlX. “2  +  GradlY. “2); 

GradMag2  =  sqrt(Grad2X. “2  +  Grad2Y."2); 

7.  aggregation 

FineScale  =  GaussianFilter(2.2,5,5)*2.2;  7.  smaller  neighborhood 
CoarseScale  =  GaussianFilter (7, 14, 14)*7;  7.  larger  neighborhood 

EMax  =  zeros  (N);  7.  evidence  map  for  best  matches 

T  =  zeros(N);  7.  translation  map 

E  =  zeros (N) ; 
elf;  shg; 


7.  Sobel  filter 
'/,  Simoncelli  filter 
7.  light  smoothing 
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for  delta  =  Translation  '/,  loop  through  translations 
*/,  evidence  measure,  E(x,y)  =  confidence  -  difference 
E  =  (GradMagl  +  Shif tlmage (GradMag2 , delta)) *0.5 

sqrt ( (GradlX  -  Shiftlmage (Grad2X, delta) ) . *2  +  (GradlY  -  ShiftImage(Grad2Y, delta)) . "2) ; 

E2  =  conv2(E,FineScale, ’same’) ;  '/.  fine-scale  matching 

i  =  find(E2  >  EMax) ; 

EMax(i)  =  E2(i) ; 

T(i)  =  delta; 

E2  =  conv2(E,CoarseScale, ’same’) ;  '/,  coarse-scale  matching 

i  =  find(E2  >  EMax) ; 

EMax(i)  =  E2(i) ; 

T(i)  =  delta; 

’/,  display  current  translation  map 

imagesc(T);  colormap(gray) ;  axis  equal;  axis  off; 

drawnow; 

end 

return; 


Shiftlmage.m 

function  Xmg  =  Shiftlmage (Img, Shift) 

‘/.SHIFTIMAGE  Translate  Img  horizontally  by  Shift 

[SizeY.SizeX]  =  size(Img); 

Img  =  [(ones (Shift, l)*Img(: ,1) ’) ’ ,Img(: ,max(l , 1-Shift) :min(SizeX,SizeX-Shift)) , . . . 
(ones(-Shift,l)*Img(: ,SizeX) ’) ’] ; 

return ; 

GaussianFilter.m 

function  f  =  GaussianFilter(Sigma,Nx,Ny) 

'/.GAUSSIANFILTER  Gaussian  convolution  filter 

’/.  f  =  GaussianFilter (Sigma, N)  makes  a  one-dimensional  filter 
’/,  f  =  GaussianFilter(Sigma,Nx,Ny)  makes  a  two-dimensional  filter 

if  nargin  ==  3 

f  =  exp(-(-Nx:Nx) . ~2/(2*Sigma~2) )/(Sigma*sqrt (2*pi) ) ; 
f  =  exp(-(-Ny :Ny) ’ . ~2/(2*Sigma~2) )/(Sigma*sqrt (2*pi)) *f ; 
else 

f  =  exp(-(-Nx:Nx) . ~2/(2*Sigma'2) )/(Sigma*sqrt (2*pi) ) ; 

end 

return ; 
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1  Scope 

1 . 1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin- film  solar  arrays. 

1.4  Document  Overview 

This  document  will  go  over  how  DINO  plans  to  determine  clouds  in  pictures. 

1 .5  Referenced  Documents 

List  any  reference  documents  here. 

2  Introduction 

The  purpose  of  the  DINO  science  mission  is  to  generate  topographic  maps  of  the 
tops  of  clouds.  Obviously,  in  order  to  do  this,  the  pictures  must  have  clouds  in  them. 
The  DINO  satellite  will  use  the  forward-looking  camera  to  take  a  series  of  pictures 
in  a  low-  resolution  preview  mode  to  search  for  clouds.  This  paper  will  cover  the 
algorithm  to  be  used  to  analyze  these  low-resolution  pictures  for  the  existence  of 
clouds. 
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3  The  Algorithm 

During  the  mission,  the  DINO  spacecraft  will  be  in  low-earth  orbit.  As  a  result,  it 
will  be  in  constant  motion.  This  means  that  only  the  leading  edge  of  the  preview 
picture  needs  to  be  analyzed  for  the  existence  of  a  cloud.  This  is  because  any  clouds 
in  the  trailing  edge  of  the  preview  picture  will  have  already  passed  by  the  spacecraft 
centerline.  In  addition,  due  to  the  spacecraft's  speed,  there  are  only  ten  seconds 
available  to  get  the  preview  picture,  analyze  it,  switch  the  camera  to  high  resolution 
mode,  and  take  the  high  resolution  picture.  As  a  result,  the  algorithm  needs  to  be 
efficient  to  meet  the  time  constraints. 

The  goal  of  the  cloud-detection  algorithm  is  to  derive  a  figure  of  merit  for  the 
existence  of  clouds  in  a  picture.  To  test  the  cloud-detection  algorithm,  the  picture 
shown  in  Figure  1  was  used. 


One  possible  approach  is  to  use  a  mask  to  give  credit  to  white  pixels  that  are 
adjacent  to  other  white  pixels  as  shown  here. 

’255  255  2551 

Pc  =  255  255  255  •  P.H  P  .  (1) 

255  255  255j  [Pi+lM  PMJ  PMJ+] 
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Where  Pc  is  a  matrix  which  gives  the  intensity  for  the  (ij)th  pixel  in  the  picture  and 
all  of  its  surrounding  pixels.  In  order  to  measure  for  white,  this  matrix  multiplication 
would  have  to  be  done  for  all  three  colors.  Then,  the  elements  of  the  rows  and 
columns  for  each  color  would  be  added  up  to  get  one  figure  of  merit  for  each  pixel. 
Then,  a  threshold  level  is  set  and  all  pixels  below  the  threshold  are  set  to  zero  and  all 
points  above  the  threshold  are  scaled  to  a  maximum  value  of  255  as  shown  in  Figure 
2. 


First  Cloud  Detection 


* 


Figure  2 


Although  this  does  show  the  cloud  shapes,  the  cloud  could  be  given  a  little  more 
recognition  by  merely  converting  all  pixels  above  the  threshold  to  a  maximum 
intensity  and  all  pixels  below  the  threshold  to  a  minimum  intensity.  This  was  done  in 
Figure  3.  This  allows  the  algorithm's  interpretation  of  clouds  in  the  picture  to  be 
readily  identified. 
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At  this  point,  however,  the  computational  intensity  of  this  method  should  be 
considered.  For  each  pixel,  it  requires  27  multiplications.  Given  the  time  constraints 
on  this  algorithm,  another  method  was  sought  to  detect  clouds.  Since  clouds  are 
white,  all  three  colors  are  nearly  equal.  A  check  was  made  and,  even  in  the  gray 
regions  of  the  clouds,  this  color  balance  remains.  In  addition,  most  terrestrial 
features  do  not  have  this  sort  of  color  balance.  Therefore  a  check  was  made  to 
determine  if  merely  checking  that  all  three  color  intensities  were  above  a  particular 
threshold  would  accurately  detect  clouds.  The  results  for  minimum  pixel  intensity 
for  each  color  of  90  are  shown  in  Figure  4. 


Page  7  of  9 


151  of  190 


PINO:  Cloud  Detection  Algorithm 


DINO-SCI-RPT-CLDS,  Rev.  B 


This  method  clearly  detects  the  clouds  with  a  nearly  two  order  of  magnitude 
reduction  in  computational  intensity. 

Now,  a  figure  of  merit  for  a  cloud  in  the  preview  picture  can  be  obtained.  Again, 
extra  credit  should  be  given  for  white  pixels  that  are  next  to  white  pixels.  If  all  white 
pixels  were  given  a  value  of  1  and  all  non-white  pixels  were  given  a  value  of  0,  then 
a  simple  addition  of  each  pixel  with  its  right-hand  and  lower  neighbors  (including 
the  diagonal  pixel)  would  produce  a  maximum  value  of  4  for  each  pixel.  Hence,  a 
maximum  value  of  4  times  the  number  of  pixels  in  the  picture  would  be  the 
maximum  figure  of  merit  that  an  entirely  cloudy  picture  would  produce. 

At  this  point,  a  threshold  level  is  needed  to  determine  when  a  cloud  exists  in  the 
picture.  The  picture  shown  in  Figure  1  has  good  cloud  coverage  and  yet  is  only  8% 
of  the  maximum  figure  of  merit.  Therefore,  a  lower  limit  of  3%  is  probably 
reasonable.  This  also  means  that  the  maximum  figure  of  merit  for  a  given  picture 
size  could  be  determined  ahead  of  time  and  the  calculations  structured  such  that  the 
white  detection  and  the  figure  of  merit  addition  occur  simultaneously  as  shown  if 
Figure  5.  Then,  as  soon  as  the  3%  limit  is  crossed,  the  detection  process  could  be 
stopped. 

Integrated  Detection  Algorithm 

pixel(g-°)®  •  o  0  •  *  0 


GOOO0OOO 


oooooooo 

Pixel(m,n) 

Figure  5 


As  Figure  5  shows,  when  testing  a  pixel,  a  pixel  would  first  be  tested  to  see  if  it  is 
white  (all  three  colors  above  the  threshold).  Then,  if  it  is  white,  its  three  neighbors  to 
the  right  and  bottom  would  be  checked  to  see  if  they  are  white.  Finally,  the  total 
number  of  white  pixels  in  this  test  group  (up  to  4)  is  added  to  the  running  total  for 
the  picture.  When  the  running  total  exceeds  0.03  times  the  maximum  possible  total,  a 
cloud  is  detected  and  the  cloud  search  is  aborted. 

Another  consideration  is  that,  ideally,  the  cloud  will  be  centered  in  the  picture. 
Therefore  when  searching  the  preview  picture  for  a  cloud,  only  the  leading  edge  and 
the  center  60%  of  the  picture  should  be  searched  as  shown  if  Figure  6.  Remember 
that  the  maximum  figure  of  merit  is  based  only  on  the  number  of  pixels  in  the  test 
region,  not  the  total  number  of  pixels  in  the  picture. 
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Potential  Cloud  Search  Region 

_ Direction  of  Flight 


Figure  6 


4  Conclusion: 

This  paper  has  given  a  method  of  detecting  the  existence  of  a  cloud  in  a  picture. 
Techniques  for  improving  the  computational  efficiency  of  this  technique  were  also 
given. 
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ANALYSIS  OF  DINO 


PROCEDURE: 

The  Analysis  was  primarily  attempted  in  ANSYS  first.  The  ANSYS  version  which  is 
installed  at  the  University  of  Colorado  at  Boulder  is  the  Student  version  and  does  not 
support  more  than  32000  nodes.  The  analysis  was  carried  out  on  individual  panels,  and 
then  the  full  assembly  was  analyzed.  ANSYS  could  not  create  a  refined  enough  mesh  for 
the  analysis.  Hence  we  looked  at  COSMOS  Works  which  is  compatible  with  Solid 
Works,  as  a  potential  option  to  run  the  analysis.  All  the  parts  have  gone  through  extensive 
frequency  analysis  in  COSMOS  Works.  It  has  been  seen  that  we  are  well  above  the  bench 
mark  of  100  Hz.  All  the  parts  were  meshed  using  the  tetrahedral  mesh  option  provided 
from  COSMOS  Works.  The  mesh  for  each  of  these  panels,  and  also  the  Full  Assembly 
has  gone  through  extensive  refinement  procedures  and  then  had  their  analysis  done. 

PROBLEMS  FACED: 

The  main  problem  first  was  inability  of  ANSYS  to  analyze  the  panels,  due  to  its 
restriction  on  the  number  of  nodes.  I  had  a  lot  of  trouble  getting  space  on  my  account 
here  at  the  Integrated  Teaching  and  Learning  Laboratory  (ITLL).  COSMOS  Works  was 
also  having  troubles  running  the  full  assembly.  I  had  to  remove  the  torque  rod  assembly 
from  the  full  assembly  because  it  had  interferences  and  COSMOS  Works  could  not 
handle  those.  It  was  not  so  critical  to  the  analysis  since  the  torque  rod  assembly  did  not 
form  major  chunk  of  the  mass  of  the  structure.  One  of  the  boxes  and  its  corresponding 
lids  needed  to  be  taken  off  due  to  some  interference  too.  One  of  the  lids  was  modified 
because  COSMOS  Works  could  not  handle  the  tolerances  for  the  mesh.  The  space 
allocation  for  the  analysis  was  also  an  issue,  since  the  simulation  used  to  just  hang  up  in 
the  same  spot  each  time.  According  to  what  the  disk  space  allocations  menu  showed, 
there  was  free  space  on  the  account,  but  COSMOS  Works,  was  unable  to  find  the  needed 
space  for  the  analysis.  Neither  did  the  Technical  Support  at  the  ITLL  know  what  was 
needed  to  be  done,  nor  did  anyone  at  MCAD,  (The  firm  that  provides  technical  support  at 
University  of  Colorado,  Boulder).  On  discussing  the  problem  with  the  Technical  support 
group  at  MCAD,  they  did  give  me  some  pointers  as  to  what  can  be  done  to  simulate  the 
whole  analysis. 

The  analysis  ran  after  9  long  days,  and  we  had  good  results. 

The  results  follow  this  order. 

The  results  for  each  of  the  individual  panels  will  be  shown  first,  they  will  be  arranged  in 
the  following  format.  The  first  mode  shape  of  each  of  these  panels  is  documented.  The 
deformation  followed  by  the  displacement  plot.  The  full  assembly  is  documented  last. 

The  panels  follow  the  order: 

1)  Bottom  Panel 

2)  Large  Panel 

3)  Side  Panel 

4)  Small  Panel 

5)  Top  Panel 

And  then  last  but  not  the  least  the  whole  Assembly. 


155  of  190 


Bottom  Panel:  First  Mode=1247.5  Hz 
Deformation  Plot: 


Model  name:  BOTTOM  PANE. 

Study  name:  BOTTOMPANB. 

Plot  type:  Frequeney-Pttl 

Mode  Shape:  1  Value-  1247.5Hz 

Deformation  Scale:  00078845 


A« 

Educational  Version.  Foi  Instructions!  Use  Only 

Displacement  Plot: 


Model  name:  BOTTOM  PANEL 
Study  name:  BOTTOAPANB. 
Plot  type:  Frequency-Pfotl 
Mode  shape:  1 

Deformation  Scale:  0.0078845 


URESOn) 

|2.217e*002 
2.032e+0Q2 
1 .848e+002 


.i,:  .1 478e+002 
.1 293e+002 
III  1.1 096*002 
,.';\9238e*001 
i#l7.390e*001 
•  ,  ^5.5436*001 

|3.695e*001 
15486*001 
0.0006*000 


Educational  Version,  For  instructional  Use  Only 


Large  Panel:  First  Mode  =  310.66  Hz 
Deformation  Plot: 


Model  name:  LARGE  SOE  PANa 
Study  name:  large  pane* 

Plot  type  Frequency -Pfctl 

Mode  Shape  :  1  Value-  31066Hz 

Deformation  Scale  0  01 021 22 


Displacement  Plot: 

Model  name:  LARGE  SIDE  PAhCL 
Study  name:  large  panel 
Plot  type:  Frequency -Plctl 
Mode  shape:  1 


Deformation  Scate  00102122 


Side  Panel:  First  Mode  =  276.65  Hz 
Deformation  Plot: 

Mode)  name:  SIDE  PANEL 
Study  name:  analyis  torside  pane* 

Plot  type:  Frequency-Ptotl 
Mode  Shape  :1  Value-  276.65  Hz 
Deformation  Scale:  0.005238 


Displacement  Plot: 


URES(in) 

123Se+002 

HLl.132e+002 

|p.1.029e*002 

92606*001 


.7202e*001 
74e*001 
|.S.145e*001 
*  4.116e+001 

13.087e.001 
2.058e*001 
1.02964001 
0.00064000 
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Small  Panel:  First  Mode  =  305.23  Hz 
Deformation  Plot: 


Displacement  Plot: 


Mode!  name:  SMALL  SCE  PANS.  THN 
Study  name:  SMALL  PANB. 

Plot  type:  Frequency-Ptotl 
Mode  shape:  1 

Deformation  Scale  0  00854172 


URES  (in) 

1.405e*002 
1.288e*002 
ll.171e*002 
.  1  054e»002 
,9.368e+001 
.8.195e*0CH 
l  .  7.024e*001 
.5  654e+001 
.  4  B83e*001 
.3.512e*001 
|^2341e+001 
Ml.171e*0O1 


Top  Panel:  First  Mode  =699.85  Hz 
Deformation  Plot: 

Model  name:  TOP  PATEL 
Study  name:  TOPPANEL 
Plot  type:  Frequency-Ptotl 
Mode  shape:  1 

Deformation  Scale:  0.0136386 


URES  (in) 

|1.278e+002 
1.1716+002 
1.065e+002 
*i'.9.582e+O01 
_8.518e+001 
7.4536+001 
-.6.388e+001 
Pi. i.  5. 3236+001 
l/i-_4.2S9e+001 
.3.1946+001 
2.1 296+001 
H.1.065e+001 
H.O.OOOe+000 


A, 

Educational  Version.  For  instructional  Use  Only 

Displacement  Plot: 


Model  name:  TOP  PANEL 

Study  name:  TOPPANEL 

Plot  type:  Frequency -Plotl 

Mode  Shape  :1  Value-  699.85  Hz 

Deformation  Scale:  0.0136366 


Education c*i  Version.  For  Instructions*  Use  Only 
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Full  Assembly:  First  Mode  =  328.78  Hz 
Deformation  Plot: 


Model  name:  Full  Assembly2 
Study  name:  full  assembly 
Plot  type:  Frequency-Plotl 
Mode  Shape :  1  Value  =  328  78  Hz 

Deformation  Scale:  0.0287412 


Version.  Foi  !n.-». 


ti-.n-.l  l 


161  of 


Displacement  Plot: 


Model  name:  Full  Assembly^ 
Study  name:  full  assembly 
Plot  type:  Frequency-Plotl 
Mode  shape:  1 

Deformation  Scale:  0.0287412 


I  I  RPC  r'ir.'i 


Educational  Version.  For  Instructional  Use  Only 
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1  Scope 

1.1  Identification 

I 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the  Colorado  Space  Grant  Consortium 
at  the  University  of  Colorado  at  Boulder.  This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by 
the  Air  Force  Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory  (AFRL),  Association 
of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard  Space  Flight  Center  (GSFC). 

1.2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as  specified  under  the  DINO  Con¬ 
figuration  Management  plan.  All  changes  and  updates  must  be  made  in  accordance  with  the  DINO  CM 
plan. 


1.3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite  Operations  (DINO)  mission  is  to 
determine  cloud  heights  from  space,  evaluate  the  performance  of  intelligent  operations,  and  assess  deployment 
technologies  for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges,  and  thin-film 
solar  arrays. 


1.4  Document  Overview 

This  document  covers  the  implementation  and  testing  of  the  various  algorithms  used  in  the  flight  software 
for  science  analysis  and  the  Attitude  and  Determination  Control  System  (ADCS). 

1.5  Referenced  Documents 

No  documents  referenced. 


2  Overview 

There  are  two  main  areas  in  the  flight  software  where  algorithmic  calculation  is  necessary:  the  science 
analysis,  and  the  ADCS  system  for  navigational  control. 


2.1  Science  Analysis 

There  are  three  main  algorithms  used  in  the  science  analysis:  cloud  coverage  detection,  stereoscopic  imaging, 
and  cloud  classification.  The  cloud  coverage  detection  algorithm  makes  use  of  the  hue  and  saturation  vaues 
of  each  pixel  in  the  image,  as  well  as  that  of  each  neighboring  pixel,  to  determine  whether  that  pixel  is  part 
of  a  cloud  or  not.  The  stereoscopic  imaging  algorithm  takes  two  images  taken  from  different  angles  and 
determines  their  depth  from  the  cameras.  Using  the  known  altitude  of  the  satellite,  the  heights  of  the  clouds 
above  Earth’s  surface  can  then  be  determined.  Finally,  the  cloud  classification  algorithm  takes  a  picture 
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of  the  clouds,  determines  the  area  within  the  image  that  the  clouds  reside,  then  using  a  neural  network 
archeticture,  attempts  to  determine  the  classification  of  the  cloud. 


2.2  Attitude  and  Determination 

The  attitude  and  determination  system  installed  in  the  flight  software  consists  of  several  different  parts  that 
interconnect: 

•  The  orbital  propogator,  which  takes  orbital  parameters  supplied  by  NORAD  and  extrapolates  them 
into  the  future  to  provide  a  predicted  model  of  the  orbit.  This  allows  for  orbital  data  to  be  sent  only 
once  every  week  instead  of  constantly,  and  provides  the  satellite  with  a  better  model  of  comparison 
with  sensor  readings. 

•  Magnetic  field  look-up  table.  The  look-up  table  is  also  provided  by  NORAD  and  provides  us  with  the 
means  to  find  our  location  above  the  Earth’s  surface  given  a  pattern  of  magnetic  readings  observed 
from  the  satellite’s  magnetometers. 

•  Actuator  control  law.  This  is  the  final  stage  of  the  control  of  the  system,  in  which  all  observed  and 
calculated  data  is  brought  together  to  determine  which  torque-rods  need  to  be  turned  on,  and  for  what 
duration  of  time. 


3  Science  Algorithms 

The  science  analyis  is  made  up  of  three  main  algorithms:  Cloud  coverage  detection,  stereoscopic  imaging, 
and  cloud  classification. 

3.1  Cloud  Detection 

The  cloud  detection  algorithm  is  a  very  simple  saturation  and  lightness  comparison  algorithm.  The  algorith 
in  pseudo-code  is  described  below. 


function  Cloud-Detect(  image  )  returns  a  percentage  of  cloud  cover 
score  <—  0 

for  each  pixel  p  in  image  from  left  to  right,  top  to  bottom  do 
result  =  PROCESSPlXEL(  Predi  Pgreeni  Vblue  ) 
if  result  =  True  then  do 
Ptotal  <  1 

score  <—  score  +1 

for  each  pixel  q  below,  to  the  right,  and  diagonally  down-right  of  p  do 
score  <^score  +qtotal 
return  score  /  imagesize  *  4 

Figure  1:  The  cloud  detection  algorithm  used  in  the  science  analysis 
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Here,  image  is  the  raw  image  taken  from  the  camera,  and  reduced  into  an  array  of  3-bit  RGB  (Red  Green 
Blue)  components  for  each  pixel.  Each  pixel  has  a  score  associated  with  it,  and  if  ProcessPixel  returns 
True  for  a  given  pixel,  its  score  is  set  to  1,  and  the  global  total  is  increased  by  1.  Then,  for  each  surrounding 
pixel,  if  their  values  are  1  as  well,  the  total  score  is  incremented  for  each  surrounding  pixel.  This  gives  a 
total  score  for  the  image  as  four  times  the  number  of  pixels  in  the  image.  The  percentage  of  cover  then  is 
a  weighted  percentage  that  takes  into  account  surrounding  pixels  below  and  to  the  right  of  the  pixel  being 
examined. 

The  ProcessPixel  function  is  shown  in  the  next  figure.  This  function  simply  examines  the  components  of 
a  pixel  in  terms  of  its  red,  green,  and  blue  color  components,  and  returns  True  if  the  saturation  and  lightness 
are  enough  to  satisfy  conditions  for  a  cloud. 


function  ProcessPixel(  pixel  p  )  returns  True  if  in  a  cloud,  False  otherwise 
average  *-  (pred  +  pgr 

een  T  Pblue)/3 

if  average  >  a  then  do 

Saturation  <  MA X-ijprediPgreemPblue)  ~  MlN(  PrediPgreeniPblue  )  /  average 
if  saturation  <  (3  then  return  True 
return  False 

Figure  2:  The  ProcessPixel  function  that  checks  each  pixel’s  saturation  and  lightness  against 
set  thresholds 

In  the  first  part  of  this  function,  the  average  of  the  three  color  components  is  taken  and  compared  against  a 
threshold  percentage  a.  If  that  passes,  the  saturation  is  taken  and  compared  against  a  threshold  percentage 
0-  If  both  tests  pass,  the  function  returns  positive,  indicating  that  the  pixel  is  white  enough  to  be  considered 
part  of  a  cloud.  Otherwise  it  returns  negatively. 

In  both  of  these  functions,  the  value  of  the  pixel  components  is  taken  to  be  a  value  between  0  and  1.  A  good 
value  of  a  seems  to  be  0.35,  while  a  good  value  for  0  seems  to  be  0.25.  These  values  have  been  experimentally 
determined,  and  have  produced  the  best  cloud  detection  results. 


3.2  Stereoscopic  Imaging 

The  stereoscopic  imaging  algorithm  used  on  DINO  is  built  in-house  by  Pascal  Getreuer  for  the  specific  goal 
of  detecting  heights  of  clouds  without  imposing  a  high  order  of  computational  requirements  on  the  flight 
computer.  The  algorithm  itself  is  based  on  Scharstein’s1  gradient-based  approach. 

There  are  four  main  parts  to  the  procedure  of  the  algorithm: 

1.  Pre-processing  filtering 

2.  Approximating  image  geradients 

3.  Multi-scale  aggregation  and  matching 

4.  Post-processing  filtering 


XD.  Scharstein.  View  Synthesis  Using  Stereo  Vision. 
Verlag  Heidelberg,  1999. 


Lecture  Notes  in  Computer  Science,  Vol.  1583,  Springer- 
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Outlined  in  Pascal’s  work  are  the  methods  of  performing  each  of  these  steps,  as  well  as  processor-saving 
approximations  and  test  results.  See  [insert  doc  name  here]  for  more  details. 

3.3  Cloud  Classification 

The  cloud  classification  algorithm  used  is  based  on  a  simple  back-propogation  neural  network  training  algo¬ 
rithm.  The  pseudo-code  of  this  algorithm  is  shown  below2. 


function  Back-Prop-Learning (  examples,  network  )  returns  a  neural  network 

inputs:  examples,  a  set  of  examples,  each  with  input  vector  x  and  output  veector  y 

network,  a  multilayer  network  with  L  layers,  weights  Wjj,  activation  function  g 

repeat 

for  each  e  in  examples  do 

for  each  node  j  in  the  input  layer  do  aj  <—  Xj  [e] 
for  l  =  2  to  M  do 

inx  <-  J2j  Wjjaj 
ai  <-  g(ini) 

for  each  node  i  in  the  output  layer  do 
Ai  <-  g'{ini)  x  (t/j[e]  -  a{) 
for  /  =  M  -  1  to  1  do 

for  each  node  j  in  layer  l  do 
Aj  <—  g'(inj)  JT  VP^A, 
for  each  node  i  in  layer  l  do 
Wjti  <—  Wjti  +  a  x  aj  x  A, 
until  some  stopping  criterion  is  satisfied 
return  NEURAL-NET-HYPOTHESls(nefu>or&) 

Figure  3:  The  back-propogation  algorithm  for  learning  in  multilayer  networks. 

The  details  of  this  algorithm  can  be  found  in  chapter  20  of  Artificial  Intelligence:  A  Modem  Approach,  second 
edition,  by  Russel  and  Norvig.  Our  particular  implementation  of  this  algorithm  takes  for  each  example  a 
gray-scale  image  of  a  cloud,  produced  from  the  cloud-detection  algorithm  above.  Using  250  to  500  training 
examples,  the  weights  of  each  unit  in  the  network  is  trained  and  stored  into  a  file.  Then,  during  use,  each 
picture  is  classified  against  these  pre-calculated  weights  and  a  result  comes  out  of  the  network. 

3.4  Testing 

The  easiest  method  of  testing  these  algorithms  is  to  take  images  of  clouds  taken  at  known  distances,  pass 
them  to  the  algorithms,  and  verify  the  results.  This  is  one  of  many  methods  we  will  use  to  verify  that  the 
algorithms  written  operate  as  expected. 

Following  is  a  summary  of  the  testing  plans  we  have,  any  testing  we  have  already  performed,  and  any  results 
we  have  obtained. 

2Algorithm  and  code  taken  from  figure  20.25,  Russel  and  Norvig:  Artificial  Intelligence:  A  Modem  Approach, 
Second  Eddition,  2003 
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3.4.1  Cloud  Detection  Testing 

The  cloud  detection  algorithm  has  undergone  the  most  testing  of  all  of  the  algorithms.  Used  in  two  balloon- 
Sat  missions,  results  indicated  that  clouds  on  the  Earth  were  reliably  and  accurately  detected  from  pictures 
taken  from  flight-model  cameras.  Returned  percentages  are  accurate  and  indicative  of  how  much  actual 
cloud  cover  exists  in  each  image.  False  detections  were  found  to  be  at  a  minimum,  but  occured  mainly  over 
buildings  and  arid  plains  (both  areas  of  high  luminosity  and  low  saturation). 

The  results  of  one  analyzed  picture  is  shown  below: 


Figure  4:  a)  Original  picture  taken  with  SupportSAT  II,  b)  processed  image.  Detected  clouds  are 
highlighed  in  green 


3.4.2  Stereoscopic  Imaging  Testing 

At  the  time  of  writing,  no  formal  testing  has  been  performed  on  the  stereoscopic  imaging  of  clouds.  However, 
plans  have  been  formulated  to  verify  the  algorithm  using  a  very  precise  angle-table  with  objects  set  at  fixed, 
known  distances.  Equipment  and  expertise  is  being  donated  from  Ball  Aerospace,  Inc.  to  aid  us  in  this 
testing. 


3.4.3  Cloud  Classification  Testing 

Initial  testing  of  the  cloud  classification  algorithm  has  shown  promising  results.  We  have  determined  that 
using  the  currently  established  infrastructure  will  require  a  relatively  fast  computer  to  do  analysis  of  clouds, 
as  the  algorithm  is  very  computationally  intense.  Initial  results  have  shown  one  image  classified  in  as  little 
as  10  minutes  to  as  much  as  an  hour,  depending  on  the  parameters  used  in  the  algorithm.  Further  testing 
will  be  performed  with  a  wider  range  of  cloud  formations,  and  in  the  end  we  will  be  using  the  algorithm 
in  our  ground  software  to  analyze  black-and-white  images  returned  from  our  cloud  detection  algorithm  on 
board  the  satellite. 
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4  ADCS  Algorithms 

The  ADCS  system  installed  on  DINO  is  a  complex,  closed-loop  system  that  is  designed  to  autonomously 
determine  and  correct  for  the  positioning  of  the  satellite  while  in  orbit.  There  are  two  main  algorithms  used 
within  this  system:  The  orbital  propogator,  and  the  actuator  control  law. 

4.1  SGP4  Orbital  Propogator 

The  SGP4  algorithm  is  an  orbital  propogation  algorithm  that  is  used  to  help  orient  the  satellite.  Given 
measurements  of  the  satellite’s  position  and  orbit  at  a  certain  time  (orbital  parameters  given  to  us  in  TLE 
format),  the  algorithm  is  able  to  calculate  where  the  satellite  is  in  its  orbit  based  on  the  ellapsed  time  since 
the  measurements  were  taken. 

The  code  for  the  algorithm  was  given  to  us  in  FORTRAN  and  translated  by  the  DINO  software  team 
into  native  Python.  The  equations  were  broken  up  into  functions  based  on  what  information  they  provide 
(e.g.  calculating  the  effects  of  atmospheric  drag  and  gravitation,  or  solving  Kepler’s  equations).  In  this  way, 
calculations  could  be  tested  part  of  the  way  through  an  iteration  to  help  in  diagnosing  errors. 

4.2  Actuator  Control  Law 

This  is  the  final  stage  of  the  control  of  the  system,  in  which  all  observed  and  calculated  data  is  brought 
together  to  determine  which  torque-rods  need  to  be  turned  on,  and  for  what  duration  of  time.  Figure  5 
details  the  flow  of  the  control  law  with  the  rest  of  the  system. 


u  =  2Kj>+K,m 

Figure  5:  Flow  chart  of  the  ADCS  control  logic 


4.3  Testing 

Testing  the  SGP4  algorithm  has  been  fairly  straight  forward.  Provided  with  the  code  for  the  algorithm  was  a 
test  case  with  the  inputs  and  outputs  of  the  algorithm  to  verify  the  implementation.  This  was  used  to  create 
a  spreadsheet  for  the  creating  of  additional  test  cases  and  to  provide  test  values  for  intermediate  calculations 
in  the  algorithm.  The  spreadsheet  performs  the  same  calculations  that  the  Python  implementation  does, 
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and  in  the  same  order.  Using  this  spreadsheet,  finding  correct  values  for  any  calculation  in  the  algorithm  is 
made  trivial,  and  provides  an  easy  way  to  test  the  software. 

To  date,  much  of  the  algorithm  has  performed  as  expected.  Additional  testing  is  being  performed  to  maximize 
the  accuracy  of  each  of  the  calculations  produced  by  the  algorithm. 

No  formal  testing  of  the  actuator  control  law  has  been  completed  to  date.  However,  proceedures  employing 
the  use  of  stringent  test  simulators  will  be  used  to  confirm  the  output  of  the  system.  We  will  also  use  real 
NORAD  orbital  information  in  these  simulations  during  satellite  day-in-the-life  testing  to  verify  that  the 
control  law  works  as  expected. 
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A  List  of  Acronyms 


Acronym 

Meaning 

ADCS 

Attitude  and  Determination  Control  System 

RGB 

Red  Green  Blue.  This  is  the  order  of  color  components  in  a  pixel  of  color 

SGP4 

An  orbital  propogation  algorithm  developed  for  NORAD  to  be  used  with  TLEs  in  pre¬ 
dicting  future  orbital  parameters. 

TLE 

Two-Line  Elements.  This  is  a  set  of  data  provided  by  NORAD  containing  information 
about  the  orbit  of  the  satellite. 
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1  Scope 

1 . 1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1.4  Document  Overview 

This  document  describes  the  TC74  thermal  sensor. 

1 .5  Referenced  Documents 

List  any  reference  documents  here. 

2  TC74 

The  TC74  is  a  serially  accessible,  digital  temperature  sensor  particularly  suited  for 
low  cost  and  small  form  factor  applications.  Temperature  data  is  converted  from  the 
onboard  thermal  sensing  element  and  made  available  as  an  8-bit  digital  word. 
Communication  with  the  TC74  is  accomplished  via  a  2-  wire  SMBus/I2C  compatible 
serial  port.  This  bus  also  can  be  used  to  implement  multi-drop/multi-zone  monitoring. 
Temperature  resolution  is  1°C  with  a  ±3C  accuracy  from  OC  to  +125C..  Conversion 
rate  is  a  nominal  8  samples/sec.  During  normal  operation,  the  quiescent  current  is  200 
pA.  During  standby  operation,  the  quiescent  current  is  5  pA.  The  TC74  are  static 
sensitive. 

3  TC74  Placement 

There  are  five  different  addresses  for  the  TC74.  Each  SMBus/I2C  can  have  only  one 
TC74  of  each  address. 
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3.1  Address  TC74A0-5.0VAT 

-  Camera  1 

o  Due  to  the  limited  space  on  the  electronics  inside  the  Camera  1  box 
it  was  decided  the  TC74  would  be  mounted  of  the  wall  of  box  as 
near  the  camera  as  possible. 

-  TNC 

o  TC74  will  be  mounted  to  the  back  of  one  of  the  TNC  boards. 

Radio 

o  TC74  will  be  mounted  on  radio  board  near  the  antennae. 

Solar  Panel  One 

3.2  Address  TC74A2-5.0VAT 

-  Camera  2 

o  Due  to  the  limited  space  on  the  electronics  inside  the  Camera  1  box 
it  was  decided  the  TC74  would  be  mounted  of  the  wall  of  box  as 
near  the  camera  as  possible. 

-  Tip  Mass  Comm  (TMC) 

o  TC74  will  be  mounted  on  the  board  by  the  antennae. 

-  Solar  Panel  Two 

3.3  Address  TC74A3-5.0VAT 

-  Magnetometer 

o  TC74  will  be  mounted  on  the  wall  of  the  box  due  to  the  small  size  of 
the  magnetometer. 

-  Power  Panel  1 

o  TC74  will  be  mounted  on  the  EPS  board  by  the  micro  controller. 
Frangibolt  One 

-  FITS 

3.4  Address  TC74A5-5.0VAT 

-  Solar  Panel  Three 

-  Power  Panel  2 

o  TC74  will  be  mounted  on  the  EPS  board  by  the  DC-DC  converters. 

-  Frangibolt  Two 

-  FITS 

3.5  Address  TC74A7-5.0VAT 

-  Solar  Panel  Four 

-  ADCS  box 

o  TC74  will  be  mounted  on  the  A/C  converter  due  to  its  abundance  of 
space. 
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4  Adding  a  Capacitor 

4.1  Reason 

A  0.1  microfarad  capacitor  was  attached  to  each  TC74  in  order  to  eliminate 
noise. 

4.2  Attaching  Capacitor  to  TC74 

4.2.1  Materials 

-  (20)  0. 1  microfarad  capacitors 

-  (20)  TC74s 

4.2.2  Procedure 

Make  sure  the  leads  of  the  TC74  are  clean  and  free  of  debris 

-  Solder  capacitor  to  lead  number  3  (ground)  and  lead  number  5  (data) 


5  Testing 

Each  TC74  was  tested  with  the  flight  computer  individually.  The  average  reading 
was  31.1  degrees  Celsius  when  tested  in  a  room  temperature  environment.  The 
largest  deviation  was  4  degrees  Celsius. 

6  Mounting  TC74 

6.1  Epoxy 

3M  Scotch  -  Weld  2216  B/A  Gray  Epoxy  Adhesives  are  flexible,  two-part, 
room  temperature  curing  epoxies  with  high  peel  and  sheer  strengths. 

6.2  Mixing  Epoxy 

6.2.1  Materials 

Epoxy  Part  A  (accelerator) 

-  Epoxy  Part  B  (base) 


6.2.2  Procedure 

Mix  7  parts  weight  of  Accelerator  with  5  parts  weight  of  Base. 

Stir  mixture  with  stir  stick  for  2  minutes  or  until  mixture  is  of  a  uniform 
color. 

-  Work  life  is  90  minutes  at  room  temperature  (74  deg.  F). 
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6.2.3  Mounting 

-  Make  sure  TC74  and  mounting  surface  is  free  of  dirt  and  debris. 

-  Cover  back  of  TC74  with  epoxy. 

Cover  desired  area  or  surface  with  epoxy  making  sure  to  completely 
cover  all  metal  leads  on  board. 

-  Place  TC74  on  desired  location  and  hold  in  place  for  2  minutes. 

-  Wipe  excess  epoxy  off  board  with  wet  cloth. 

Keep  TC74  in  a  horizontal  position  to  avoid  slipping. 

-  Wait  24  hours  for  epoxy  to  dry. 

-  Taping  sensor  in  place  is  permissible 
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1  Scope 

1.1  Identification 

This  document  applies  to  the  DINO  project,  a  project  undertaken  by  the 
Colorado  Space  Grant  Consortium  at  the  University  of  Colorado  at  Boulder. 
This  project  is  part  of  the  Nanosatellite  III  Program  sponsored  by  the  Air  Force 
Office  of  Scientific  Research  (AFOSR),  Air  Force  Research  Laboratory 
(AFRL),  Association  of  Aeronautics  and  Astronautics  (AIAA),  and  Goddard 
Space  Flight  Center  (GSFC). 

1 .2  Document  Maintenance 

This  document  falls  under  the  DINO  document  control  requirements  as 
specified  under  the  DINO  Configuration  Management  plan.  All  changes  and 
updates  must  be  made  in  accordance  with  the  DINO  CM  plan. 

1 .3  Systems  Overview 

The  purpose  of  the  student-led  Deployment  and  Intelligent  Nanosatellite 
Operations  (DINO)  mission  is  to  determine  cloud  heights  from  space,  evaluate 
the  performance  of  intelligent  operations,  and  assess  deployment  technologies 
for  nanosatellites  including  a  gravity-gradient  boom,  memory  composite  hinges, 
and  thin-film  solar  arrays. 

1.4  Document  Overview 

This  document  explains  the  interfaces  existing  on  the  Tip  Mass  module: 

-  Tip  Mass  radio  interface  with  the  Microcontroller 

-  Microcontroller  interface  with  the  On-board  motion  sensors 

AND  the  radio  interface  with  the  Flight  computer  on  the  main  satellite  module 

1 .5  Referenced  Documents 

http://rex.colorado.edu/svn/dino/trunk/hardware/tipmass/schematic.pdf 

http://rex.colorado.edu/svn/dino/tnmk/hardware/tipmass/aux-schematic.pdf 

2  The  Wireless  Link 

Wiser  2400  (802.1  lb)  radios  provide  conversion  of  serial  (RS-232)  data  interface  to 
the  802.1  lb  wireless  interface.  The  serial  end  of  the  interface  will  connect  to  the 
flight  computer  (on  the  main  satellite  module)  and  the  microcontroller  (PIC16C77  on 
the  Tip  Mass  side).  The  wireless  interface  will  provide  the  link  between  the  flight 
computer  and  the  Tip  Mass  separated  by  a  distance  of  6m  as  shown  in  Figure  1 . 
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RS-232  serial 


Serial  RS232 
port  on  the  PIC 


Figure  1 


2.1  Specifications 

Specifications  of  the  Wiser  2400  radios:- 

-  Frequency:  ISM  band  (2.4GHz  -  2.495GHz) 

-  Voltage,  current:  5v,  max  480mA  (in  transmit  mode) 

Data  rate:  Configured  for  1 15K  baud 

-  Weight :  2.0  ounces 

Antenna  type:  Integrated  dipole  antenna  (omni-directional)  with  ~2dBi 
gain 

2.2  Radio  Propagation  Tests 

2.2.1  Procedure  for  Test  1 

The  radios  were  tested  in  a  no-obstruction  environment.  The  orientation  of 
the  two  radios  was  switched  from  Vertical  (V)  to  Horizontal  (H)  and  the 
subsequent  measurements  were  recorded  at  increasing  distances. 

Table  1  summarizes  the  measurements. 

2.2.2  Results  for  Test  1 


Table  1 


Distance 

wiser  1-V, 
wiser2-V 

wiser  1-H, 
wiser2-H 

wiser  1-V, 
wiser2-H 

Wiser  1-H, 
wiser2-V 

(m) 

signal 

level 

(dbm) 

signal 

level 

(dbm) 

signal 

level 

(dbm) 

signal 

level 

(dbm) 

12 

-71 

-67 

-76 

-62 

20 

-71 

-71 

-72 

-72 

33 

-78 

-78 

-75 

-75 
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2.2.3  Conclusion: 

The  losses  were  higher  than  that  estimated  using  Link  Power  budget  but 
were  low  enough  to  sustain  an  error-free  transmission  for  a  significant 
distance  range.  The  omnidirectional  antenna  assures  that  the  signal  level  is 
satisfactory  for  any  orientation  of  the  radios  with  respect  to  each  other. 

2.2.4  Procedure  for  Test  2 

The  second  set  of  radio  measurements  were  made  with  the  radios  enclosed 
in  an  isogrid/metal  box.  The  isogrid  can  induce  a  faraday  cage  effect  for  the 
2.4GHz  frequencies.  This  was  performed  because  the  final  structure  will 
have  the  radio  enclosed  in  a  metal  box  (although  the  design  will  have  a 
provision  for  the  antenna  (dipole)  to  be  protruding  out  of  the  box)  mounted 
on  an  isogrid. 


2.2.5  Results  for  Test  2 


Figure  2 


•  Signal  level:  -70dBm 

•  Radio  placed  in  the  open  (without  obstruction) 

•  Signal  level  measurements  taken  all  around  a  circle  of  radius  8-8. 5m 

•  Signal  range:-65dbm  to  -73dbm 

•  Frame  transmission  rate  at  1 1Mbps 
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Figure  3 


•  Radio  placed  under  the  solid  metal  plate. 

•  Signal  level  measurements  taken  all  around  a  circle  of  radius  8-8. 5m 

•  Signal  range:-76dbm  to  -8 1  dbm 

•  Frame  transmission  rate  at  1 1Mbps 
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Figure  4 


•  Radio  placed  between  the  solid  metal  plate  and  the  ‘isogrid’ 

•  Signal  level  measurements  taken  all  around  a  circle  of  radius  8-8. 5m 

•  Signal  range:-78dbm  to  -82dbm 

•  Frame  transmission  rate  at  1 1Mbps 


2.2.6  Conclusion 

Under  simulated  conditions  the  radio  performed  well  for  the  link  distance 
expected  in  the  deployed  state.  A  distance  margin  is  also  accounted  for. 


2.3  Interface  Customization 

The  Wiser  2400  radios  were  modified  to  meet  the  interface  requirements  at  the 
serial  connections.  There  were  two  serial  connections  for  the  two  radio  units 
respectively: - 

•  On  the  Tip  Mass,  interface  with  the  PIC 

•  On  the  main  satellite  module,  interface  with  the  Flight  computer 
Figure  5  shows  the  internal  pin  configuration  for  the  Wiser  2400  radio  PCBs. 
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LABEL 


The  pin-outs  for  the  radio  are  shown  above.  Table  2  maps  pins  1-8  in  the  above 
figure  to  the  pins  provided  on  the  flight  computer  for  the  Tip  Mass 
communication  system 


Table  2 


Radio 

Fight  Computer 

Pin  2  (Tx) 

Pin  3  (Rx) 

Power  +5V 

Pin  5  and  Power  GND 

Table  3  provides  the  mapping  between  the  pins  1-8  on  the  radio  side  and  the 
PIC16C77 


Table  3 


Radio 

PIC16C77 

Pin  2  (Tx) 

Pin  14  (DOUT1) 

Pin  4  (Rx) 

Pin  13  (RIN1) 

Pin  3  (RTS) 

Pin  7  (DOUT2) 

Pin  5  (CTS) 

Pin  8  (RIN2) 
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3  Science  Incorporated  on  the  Tip  Mass 

The  Tip  Mass  Science  board  measures  rate  of  rotation  and  acceleration  on  all  3  axis, 
which  will  allow  for  accurate  recreation  and  modeling  of  the  deployment  of  the  Tip 
Mass  module.  The  measurements  are  accomplished  through  the  use  of  3  rate  gyros 
and  2  dual  axis  accelerometers. 

3.1  Tip  Mass  Science  Hardware 

3.1.1  Rate  Gyros 

The  Rate  Gyros  are  the  ADXRS150EB  ±  1507s  Single  Chip  Yaw  Rate 
Gyros.  It  was  decided  to  use  these  gyros  because  of  the  familiarity  with 
these  devices  from  other  space  grant  projects.  The  ADXRS150  deliver 
an  analog  output  signal  that’s  voltage  is  proportional  to  the  angular  rate 
of  rotation  about  the  axis  normal  to  the  top  surface  of  the  package,  see 
Figure  6.  This  signal  is  then  converted  into  a  digital  signal  and  stored  in 
a  data  log  on  the  Tip  Mass,  to  be  later  sent  to  the  main  DINO  module. 
The  package  used  is  Tip  Mass  science  has  the  rate  gyro  on  a  factory 
mounted  evaluation  board,  which  was  decided  on  because  it  would  be 
easier  to  integrate  and  mount  on  the  Tip  Mass  PCB  board. 

RATE  RATEOUT 


Figure  6:  RATEOUT  Signal  Increases  with  Clockwise  Rotation 
3.1.2  Rate  Gyros  Testing 

The  rate  gyro  circuitry  was  constructed  on  a  “prototyping  board”  with 
the  corresponding  components.  A  voltmeter  was  placed  in  the  output  of 
the  circuit.  Variable  power  supplies  were  utilized  to  simulate  the  input 
voltages  of  the  +5VDC  power  supplies.  The  circuit  was  then  rotated  in 
each  direction  to  verify  correct  response  of  the  rate  gyro.  The  rate  gyro 
was  also  verified  to  have  insignificant  drift  by  placing  it  in  a  stable 
atmosphere  (i.e.  not  rotating)  and  taking  data  for  48  hours.  The 
following  figure,  Figure  7  displays  the  results  of  this  test. 
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Figure  7:  Rate  Gyro  48hr  Test  Results 

The  rate  gyro  had  no  drift  when  average  value  of  the  output  is  taken. 
The  null  rate  is  approximately  2.5VDC  and  will  have  to  be  taken  from 
the  individual  rate  gyros  before  launch  to  verify  the  values  in  software. 
This  value  will  also  be  affected  by  the  signal  conditioning  circuitry.  The 
circuits  were  tested  individually  in  the  same  manner  after  they  were 
manufactured  and  populated.  After  testing,  the  circuits  were 
functionally  tested  with  the  completed  Tip  Mass  electronics. 

3.1.3  Accelerometers 

The  two  dual  axis  accelerometers  used  on  Tip  Mass  are  the  ADXL311 
±2  g  Dual  Axis  Accelerometers.  The  ADXL311  can  measure  both 
dynamic  acceleration  (e.g.,  vibrations)  and  static  acceleration  (e.g., 
gravity).  The  output  is  an  analog  voltage  that  is  proportional  to  the 
acceleration.  The  high  accuracy  and  small  acceleration  range  is 
achieved  because  of  the  slow  deployment  of  the  Tip  Mass,  which  is 
expected  to  be  at  its  maximum  less  than  1  g.  See  Figure  8  for  functional 
block  diagram. 
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Figure  8:  Functional  Block  Diagram  of  Accelerometers 


3.1.4  Accelerometers  T esting 

The  accelerometers  were  all  individually  hooked  up  to  an  oscilloscope 
and  each  was  verified  for  proper  operations.  The  null  rate  is 
approximately  2.5  VDC,  and  using  the  earth’s  gravitation  force  it  was 
viewed  that  the  actual  range  of  measurable  acceleration  for  these  devices 
is  approximately  ±4  g,  high  then  the  rated  ±2  g.  From  this  it  was 
determined  that,  using  8  bit  encoding,  that  an  obtainable  resolution  of  15 
mg  is  achievable. 


